Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 095 / 131adoc1.arc / RBBS-PC1.DOC

Wrap

Text File | 1985-12-23 | 233.4 KB | 5,042 lines

REMOTE BULLETIN BOARD SYSTEM for the IBM Personal Computer Version CPC13.1 Copyright 1983, 1984, 1985 by D. Thomas Mack 10210 Oxfordshire Road Great Falls, Virginia 22066 VOICE -- (703) 759-4357 DATA #1 -- (703) 759-5049 #2 -- (703) 759-9659 AND Jon Martin 4396 N. Prairie Willow Ct. Concord, California 94521 DATA -- (415) 689-2090 December 1, 1985 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 TABLE OF CONTENTS Page ----------------- ---- 1.0 INTRODUCTION 6 1.1 The Capital PC User Group 1.2 The "contributions" requested for RBBS-PC 1.3 The "history" behind RBBS-PC 7 1.4 RBBS-PC Update Conventions 12 1.5 An Example of "Users Helping Users" 13 1.6 What's new with CPC13.1A 14 2.0 RBBS-PC "BASE-LINE" HARDWARE REQUIREMENTS 20 3.0 RBBS-PC's SUPPORT POLICIES 22 3.1 RBBS-PC's Vendor Support Policy 3.2 RBBS-PC's User Support Policy 25 4.0 OPERATING SYSTEM REQUIREMENTS 26 5.0 HOW TO GET A COPY OF RBBS-PC SENT TO YOU 27 6.0 FILES RBBS-PC USES 28 6.1 RBBS-PC System Files 30 6.2 RBBS-PC Text Files 32 7.0 USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC CPC13 34 7.1 Global RBBS-PC Parameters (Part 1 of 2) 34 7.1.1 SYSOP's Name and Password for Remote Access 7.1.2 Password to Locally Take Over RBBS-PC as SYSOP 35 7.1.3 SYSOP's Default Sign-on Mode 7.1.4 SYSOP's "office" Hours 7.1.5 Use of Printer Bell 7.1.6 Number of Rings RBBS-PC Waits Before Answering 7.1.7 Deny Access to Callers Who Use 300 Baud 36 7.1.8 Are You Using ANSI.SYS With A Color Monitor 7.1.9 Go Off-line Whenever A Disk Full Occurs 37 7.1.10 Prompt Sounds 7.1.11 Maximum Time per Session 7.1.12 Limit Maximum Time on System Per Day 38 7.1.13 Months of Inactivity before a User is Deleted 7.1.14 Communication Port to be Used 7.1.15 Version of DOS RBBS-PC Will Run Under 7.1.16 Name of RBBS-PC 7.2 Global RBBS-PC Parameters (Part 2 of 2) 38 7.2.1 Color Monitor's Foreground/Background/Border 7.2.2 Selecting the Modem Speaker On or Off 39 7.2.3 Reminding Users of Messages They Left 7.2.4 Remind Users of Uploads and Downloads 7.2.5 Remind Users of Their Profile Preferences 7.2.6 Default User Page Length 7.2.7 Maximum Number of Lines per Message 7.2.8 Requiring non-ASCII Protocol for Binary Files 7.2.9 MICROCOM's MNP Protocol 7.2.10 Omitting First Level Directory in "New" Command 40 7.2.11 Omitting Upload Directory in "New" Command 7.2.12 Making System "Welcome" Interruptible 7.2.13 Making System Bulletins "Optional" Page 2 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 TABLE OF CONTENTS (continued) Page ----------------------------- ---- 7.2.14 Type of PC RBBS is Running On 41 7.2.15 Issuing Modem Commands Between Rings 7.2.16 Baud Rate to Initially Open Modem At 7.2.17 Seconds Waited Before Logging Off Idle Users 7.2.18 Using "Dumb" Modems 7.3 Parameters for RBBS-PC "text" Files 42 7.3.1 Drive Containing RBBS-PC "Bulletins" 7.3.2 Name of File Describing "Bulletins" 7.3.3 Number of System Bulletins 7.3.4 Prefix Used to Name Bulletin files 7.3.5 Drive Containing On-line Help Files 7.3.6 Prefix Used to Name Help Files 7.3.7 Name of "NEWUSER" File 7.3.8 Name of "WELCOME" File 43 7.3.9 Name of File Describing File Directories 7.3.10 Name of SYSOP's Command Menu 7.3.11 Name of Messages Subsystem Command Menu 7.3.12 Name of File Subsystem Command Menu 7.3.13 Name of Utilities Subsystem Command Menu 44 7.3.14 Menu that Lists Available Conferences 7.3.15 File Containing Invalid User Names 7.3.16 Factor to Extend Session Time for Uploads 45 7.3.17 Default System Type for New Users 7.3.18 Drive Available for Uploading 7.3.19 Name of Directory to Update for Uploads 7.3.20 Drives Available for Downloading 7.4 Parameters for RBBS-PC "system" Files 45 7.4.1 Name of "MESSAGES" File 7.4.2 Name of "CALLERS" File 7.4.3 Name of File Containing "Comments" for the SYSOP 46 7.4.4 Name of "USERS" File 7.4.5 Extended Logging to "CALLERS" File 7.5 Parameters for RBBS-PC "Doors" 46 7.5.1 Enabling the "Door" Subsystem 7.5.2 Name of Menu that Lists the Available "Doors" 7.5.3 File RBBS Builds Dynamically to Open a "Door" 47 7.5.4 File to Re-invoke RBBS-PC When a "Door" Closes 7.5.5 Drive to Look for COMMAND.COM On 7.6 Parameters for RBBS-PC's Security 47 7.6.1 Minimum Security Level to Get Into RBBS-PC 7.6.2 Default Security Level for New Callers 7.6.3 Default Security Level for SYSOP 7.6.4 File of File Names With Download Security 48 7.6.5 Minimum Security Level to See SYSOP's Menu 7.6.6 Minimum Security Level to Use RBBS-PC "Doors" 7.6.7 Maximum # of Security Violations Before Lockout 7.6.8 Security Level(s) for Each Command 7.6.9 File With Privileged Group Passwords 7.6.10 Maximum Number of Password Changes Per Session 49 7.6.11 Minimum Security For Temporary Password Changes 7.6.12 Minimum Security to Overwrite Files on Uploads 7.6.13 Security Level of Conference "Viewers" 7.6.14 Security Levels Exempt from Purge of User File Page 3 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 TABLE OF CONTENTS (continued) Page ----------------------------- ---- 7.7 Parameters for Multiple RBBS-PC's/Conferences 49 7.7.1 Maximum Number of Concurrent RBBS-PC's 7.7.2 Environment Running Concurrent RBBS-PC's 7.7.3 Method RBBS-PC Uses to "Recycle" When User Logsoff 50 7.7.4 Maximum Number of Records in the "USERS" File 7.7.5 Maximum Number of Records in the "MESSAGES" File 7.7.6 Maximum Number of Messages Allowed 51 7.7.7 Conference File Maintenance 7.8 RBBS-PC SYSOP Utilities 51 7.8.1 Packing the "MESSAGES" File 7.8.2 Rebuilding the "USERS" File 52 7.8.3 Printing Message Header Records 7.8.4 Renumbering Messages 7.8.5 Repairing the MESSAGES File 7.8.6 Initialize Hayes 2400 Firmware for RBBS-PC 7.9 Use of DOS Subdirectories 53 7.9.1 Using DOS Subdirectories 7.9.2 Upload DOS Subdirectory 7.9.3 Download DOS Subdirectories 7.9.4 List, Change, Add, Delete DOS Subdirectories Used 8.0 THE HAYES MODEM SWITCH SETTINGS AND CONSIDERATIONS 54 8.1 Hayes Modem Switch Setting Considerations 8.2 Hayes Command's Considerations 55 9.0 USING MULTIPLE FILE DIRECTORIES 57 10.0 SETTING UP ".BAT" FILES FOR RBBS-PC 58 11.0 THE USE OF RBBS-PC "DOORS" 59 12.0 THE SECURITY FEATURES OF RBBS-PC 61 12.1 RBBS-PC's Security Features 12.2 Examples of Uses for RBBS-PC's Security System 62 12.3 How to Implement the Password File 63 12.4 How to Implement the Security for Download Files 64 12.5 How to Implement the Security for RBBS-PC Commands 65 12.6 Beware of the "Trojan Horse" 67 13.0 SYSOP FUNCTIONS 68 13.1 SYSOP Commands Within RBBS-PC 13.2 SYSOP's Use of Function Keys 69 14.0 DOS LIMITATIONS ON RUNNING PROGRAMS REMOTELY 72 14.1 How to Get DOS to Monitor Carrier Detect 14.2 How to Redirect Graphic Displays to Remote Users 73 15.0 CONFERENCING WITH RBBS-PC 74 16.0 UPLOADED FILE TIPS 76 17.0 DUE WARNING AND SYSOP'S LEGAL LIABILITY 77 Page 4 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 TABLE OF CONTENTS (continued) Page ----------------------------- ---- 18.0 COMPILING AND LINKING RBBS-PC 78 18.1 Compiling CONFIG.BAS and RBBS-PC.BAS 18.2 LINKing CONFIG 18.3 LINKing RBBS-PC 19.0 LIMITED LICENSE 80 20.0 LIMITED WARRANTY 81 21.0 UPGRADING FROM CPC12-5B TO CPC13-1A 82 22.0 RBBS-PC FUTURE DIRECTIONS 83 APPENDICES: A -- RBBS-PC Record Formats 85 B -- RBBS-PC Vendor Protocol Interface Specifications 89 C -- RBBS-PC in a MultiLink Environment 90 D -- RBBS-PC in a CORVUS Network 92 E -- RBBS-PC in an ORCHID or AST PCnet Network 93 F -- RBBS-PC and the Hearing-Impaired 101 G -- RBBS-PC and the IBM PCjr 102 H -- RBBS-PC Subscription Service 105 I -- RBBS-PC National Listing Service 106 J -- RBBS-PC and the Ark-Paradyne Modem Switch Settings 107 K -- RBBS-PC and the AT's RS-232 Cable 108 Page 5 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 1.0 INTRODUCTION ---------------- RBBS-PC is a Remote Bulletin Board System for the IBM personal computer, hence the name RBBS-PC. RBBS-PC has two fundamental purposes -- to be a catalyst for the free exchange of information, and to serve as an educational example of what can be done with BASIC. I distribute RBBS-PC under the trademark "Userware" because RBBS-PC is the sure and present proof that software which is shared becomes better than it was. RBBS-PC is the result of many thousands of man-hours of effort and is what it is today because of the many software contributions and suggestions by members of the Capital PC Users Group and others. Everyone has something that they believe strongly in. For me it is the "Userware" concept and the free exchange of information. As John Naisbitt states in his book, MEGATRENDS, "...the new source of power is not money in the hands of a few, but information in the hands of the many." For this reason I have devoted the time I have in writing, maintaining, and enhancing RBBS-PC over the years. The reason that I am the registered copyright owner of RBBS-PC and grant the limited license that I do is to primarily insure that these purposes are not abrogated. 1.1 The Capital PC Users Group ------------------------------ Because the fundamental purposes of RBBS-PC and the Capital PC Users Group are similar, I package and forward each new version of RBBS-PC to the CPCUG's Software Exchange for distribution. The Capital PC User Group is a Maryland Corporation whose "legal name" is the Capital PC User Group Inc. The CPCUG is a non-profit organization according to Section 501C4, Social Welfare, of federal law. All revenues are re-invested in and applied to the CPCUG's education programs. 1.2 The "contributions" requested for RBBS-PC ---------------------------------------------- The "logo" of RBBS-PC requests contributions. This is because the RBBS-PC may be perceived as an advantage to user-groups, businesses, or government agencies. It is hard to put a value on the RBBS-PC as it varies from organization to organization and from time-frame to time-frame. The first and most desirable level of "contribution" is public domain software sent to the Capital PC Software Exchange (P.O. Box 6128, Silver Spring, MD 20906). This requires that you or your organization take the time and trouble to document whatever you wish to share. I would advise you to be prepared to convince your organization's legal department that IBM PC utilities, "peeks/pokes", etc. are sharable with the world in general. Often these are perceived as "proprietary" and lawyers tend to view software contributions to the "public domain" as the needless jeopar- dizing of your organization's technical dominance. This legal myopia over- looks the fact that "public domain" software can be used to establish your organization's technical dominance. If you have a new PC hardware product, "public domain" software that demonstrates it's potential may be just the marketing strategy to create a demand for the product. If you are a consulting organization, your technical reputation may be widely spread through "public domain" software. Page 6 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 If you wish to contribute software but don't wish it to be "public domain," consider contributing it under a limited license similar to the one under which RBBS-PC is distributed (see section 19). The next level of "contribution" is equipment or services. Be inventive in light of the CPCUG's objectives under 1.1. If you or your organization can donate equipment, software, supplies, or services to the CPCUG, feel free to do so. If you are so inclined, but before you do so, contact the Capital PC User Group, P.O. Box 3189, Gaithersburg, MD 20878. For general information about the appropriateness of the bequest, contact the Capital PC User Group directly. The last level of "contribution" is merely money. This is the one commo- dity that we are willing to exchange among each other without first having obtained the respect, consideration, etc. of the other party. It is per- haps the easiest to give as it exonerates us from the other levels of "contribution." CPCUG is an all volunteer organization and, of course, money is seldom plentiful. However the essence of CPCUG is the time, ideas, and effort that each of the volunteers contribute to it. For this reason, while money is always appreciated, money is not the best or even the second-best type of "contribution" you could make. Independent of whether you can donate public domain software, equipment, services, supplies, or money, consider becoming a member of CPCUG. If you wish to become a member of CPCUG, simply send your name, address, home/work phone numbers along with $25 to CPCUG, P.O. Box 3189, Gaithersburg, MD 20878. If in the final analysis you feel that you can do none of the above, o remember those who have, o enjoy what they have nurtured, and o keep the faith with those who have gone before you. 1.3 The "history" behind RBBS-PC -------------------------------- Electronic bulletin board systems have been around ever since personal computers existed. The first ones were very primitive and usually consisted of some posted notices and maybe allowed for on-line messages. It must be remembered that the IBM PC was only announced in August of 1981 and first became available in October of 1981. Therefore it is not supprising that the early history of BBS' is associated with non-IBM personal computers. The "early history" of bulletin board systems began around 1978 in Chicago with the CBBS/Chicago (Computerized Bulletin Board System/Chicago). It was created by Ward Christensen and Randy Suess -- members of the Chicago Area Computer Hobbyist Exchange (CACHE). CBBS for the CP/M is written in 8080 Assembler language (11,000 lines of it) and, like the early versions of RBBS-PC (i.e. prior to CPC12-5A), detects the baud rate and the parity of the user when he first signs on from the three carriage returns that the user must enter. About the same time, Bill Abney wrote a BBS for the Radio Shack TRS-80 Models I and II called Forum-80. Page 7 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 The earliest BBS that I know of was written for the Apple (who else had personal computers in those days?) called the "Apple Bulletin Board System" (ABBS). It was written by Craig Vaughn and Bill Blue. They later created another bulletin board system for the Apple II called the People's Message System (PMS). Another Apple bulletin board system that came into being was for the Apple II, II+, and IIE as well as the Franklin Ace and it was called the CommuniTree. It was written in the FORTH language by Dean Gengle and several others. When IBM announced its first personal computer, the IBM PC, in August of 1981, there was no BBS for it. In the summer of 1982, Brad Hanson found a prototype version written by Russ Lane in IBM's BASIC on the Dallas R/CPM\CBBS system. Brad added many fixes and modifications. In the first half of 1983, many members of the Capital PC Users Group's Communication Special Interest Group (SIG) such as Larry Jordan, Rich Schinnell, Gary Horwith, Jim Fry, Scot Loftesness, and Dorn Stickle further enhanced it and added XMODEM file transfer capability until it became known as RBBS-PC CPC 09 in May of 1983. At that time each feature or modification was identified by a new version number; it still ran only under the BASIC interpreter; and was both relatively slow (because of the interpreter) and somewhat unstable (it would normally "crash" at least once each day). Late in May of 1983, I asked Rich Schinnell if there was any "bulletin board" software available for the IBM PC written in BASIC. Rich told me to give Larry Jordan a call. Larry said that he was just getting CPC09 ready to send to Rich Schinnel who at that time was Director of the Capital PC User Group's Public Domain Software Library and that I could get it from Rich. I did, and still have the diskette just as Rich sent it to me -- dated June 22, 1983. Bulletin board systems, historically were the result of a single person or small group of persons' efforts and tended to serve a very narrow interest group -- typically those interested in the medium itself (i.e. PCs, programming, communications, etc.). This was true up to and including RBBS-PC CPC09. In fact, most of the incentive to get the public domain versions of RBBS (CPC09 and earlier) functioning was to introduce the XMODEM protocol to the IBM PC-based community. In this CPC09 was successful and may have been the primary incentive for XMODEM to be included in PC-TALK at all. Since June of 1983 I have authored and released TWENTY-SIX versions of RBBS-PC and distributed them exclusively through the Capital PC User Group under the limited license described in section 19 of this documentation. At this time RBBS-PC appears to have become the "industry standard" for IBM-type personal computer bulletin board systems. However, even from the very beginning BBSs have excelled whenever: a.) there was a geographically dispersed audience, b.) with a need to exchange highly complex/technical information, c.) in a timely and accurate manner. Page 8 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 RBBS-PC's impact has been to open an entirely new medium of communications between people. Rather than as an end in and of itself, RBBS-PC has come to serve as a means to an end -- the free exchange of ideas. On a technical level it is certainly an example that shows "real programmers can/do program in BASIC." I would like to think that RBBS-PC had something to do with IBM and Microsoft coming out with new versions of the BASIC compiler that support communications, sub-routines, local and global variables, file-locking in a networking environment, etc. RBBS-PC represents a fundamental cornerstone, not just a phase, in what can be viewed as a "social rennaissance." The three areas that I mentioned earlier in which bulletin boards excel seem to ebb and flow within communities and organizations. RBBS-PC provides an almost instantaneous mechanism by which these needs can be met. Many of the Big 8 accounting firms bring up RBBS-PC's just to fulfill one contract so that the various geographically disbursed members on the contract can communicate across time zones and continents. Unlike radio, newspapers, and television -- RBBS-PC provides a vehicle within which information can be EXCHANGED! That is what makes RBBS-PC so unique. Because the exchange is written, it is structured. Because it is structured, it can be thoughtful. The "social renaissance" that RBBS-PC represents is the electronic elimination of those barriers that had previously inhibited the "exchange" of information within our society. RBBS-PC provides every personal computer owner with his own "soap-box" in a national Hyde Park. Previously the channels of communication had built-in barriers to "exchange"; with RBBS-PC those barriers begin to cease to exist. While only the most fanatical RBBS-PC trivia experts may be interested, I've gone back and checked all the documentation and releases of RBBS-PC that I've authored and here is the tedious chronolgy: RBBS-PC Version Release Date of Major Enhancements Number First Version CPC10.0 07/04/83 RBBS-PC first written to be compilable by IBM's BASIC compiler, version 1.0 CPC11.0 08/10/83 RBBS-PC restructured so that all parameters were external (i.e. in the RBBS-PC.DEF) allowing SYSOPs who didn't want to spend the $300 for the BASIC compiler to tailor RBBS-PC to their taste. CONFIG.BAS was first written to generate RBBS-PC.DEF. CPC11.1 09/15/83 Jon Martin contributed UTSPACE.OBJ, a sub- routine that allowed the compiled version of RBBS-PC to determine the amount of free space available for uploading. CPC11.2 10/01/83 The error trapping within RBBS-PC was completely re-written to be more comprehensive. CPC12.0 10/28/83 Tree-structured file directories and the ability to detect that RBBS-PC was in a Page 9 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 RBBS-PC Version Release Date of Major Enhancements Number First Version "MultiLink" environment were incorporated. "MultiLink" is a product of the Software Link, Inc. which allows DOS 1.1, 2.0, 2.1, and 3.0 to be "multi-tasking." CPC12.1 12/18/83 The ability for a SYSOP who signed on (Versions A-F) remotely to drop into DOS was added. Also the "New" command was added that allowed users to determine what new files had been made available since the last time they were on. CPC12.2 04/08/84 The security system designed by Ken Goosens (Versions A-D) was incorporated. RBBS-PC's security system has an elegance unmatched even by the largest mainframe. In essence it is a "self-locking lock." Despite the fact that the RBBS-PC source code is distrbuted with RBBS-PC, the security system within RBBS-PC that Ken designed has remained unbroken. Of course, SYSOPs who didn't adhere to RBBS- PC's security structure have had their system "crashed" and every SYSOP should operate as if the very next caller could crash his system. CPC12.3 11/11/84 This was almost as complete and as major a (Versions A-B) re-write of RBBS-PC as CPC10.0 had been. Beginning with CPC12.3 up to nine RBBS-PCs can share the same files in either a multi- tasking DOS environment (i.e. MultiLink from the Software Link, Inc.) or in a local area network environment (i.e. Corvus or Orchid). CPC12.4 03/10/85 RBBS-PC's stature in the industry became (Versions A, recognized when, as author of RBBS-PC, I A1, and B) was granted a license by Microcom to incorporate their proprietary MNP protocol into RBBS-PC. Almost at the same time many manufactures recognized the institution that RBBS-PC had become in our industry and elected to include "RBBS-PC compatibility" in their minimum criteria for the introduction of their new products. RBBS- PC's Vendor Support Program is more fully explained in the RBBS-PC documentation but one direct result of this was the intro- duction of 300/1200/2400 BAUD support in CPC12.4A before most such modems were generally available. CPC12-5 07/14/85 RBBS-PC was enhanced to allow 36 copies of (Versions A RBBS-PC to share the same files in a network and B) environment. RBBS-PC automatically answers Page 10 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 RBBS-PC Version Release Date of Major Enhancements Number First Version the phone and no longer requires each caller to enter up to 3 carriage returns in order for RBBS-PC to detect the users baud rate and parity. Logon to RBBS-PC has been made much more efficient with the USERS file no longer being searched sequentially and the MESSAGES file no longer being read three times. Version CPC12-5B, released August 25, 1985, WAS THE LAST VERSION COMPILABLE BY VERSION 1.0 OF THE IBM BASIC COMPILER! CPC13-1 RBBS-PC was completly rewritten to be (Version A) compilable by both the Version 2.0 of the IBM BASIC compiler ($495 list price) and Microsoft's QuickBASIC Version 1.0 ($99 list price). XMODEM with CRC was added as a file- transfer protocol as well as the ability to display on the color monitor of the PC running RBBS-PC the color/graphics that the remote user sees exactly as he sees them. During the evolution of RBBS-PC I have had the distinct privilege of working with many contributors. Contributions have ranged from suggestions, to software fixes, to significant enhancements, to improved documentation. While I have met very few of these people personally, those whose names I remember are: Randy Brodersen Gary Horwith Juergen Nordhausen Mike Brown Charlie Innusa Harvey Pierce Rob Cecchino Loren Jones Danny Plunkett Drew Commins Larry Jordan James Reinders Everett Delano Robert Jueneman Dick Rohrdanz Don Dewall Verne Kallejian Rich Schinnell Jim Fox Steven Linhart Mark Seiden Warren Fox Scott Loftesness Andrew Silber Asa Fulton Harry Logan Carl Spencer Jim Fry Tom Mack David Staehlin Kent Galbraith Jon Martin Dorn Stickle John German Robert Mahoney Terry Steichen Read Gilgen Sidney Markowitz Yew Seng Tan Ken Goosens Wes Meier David Terry Dave Hacquebord Bill Newkirk Arnold Thomsen Steve Harrison Clark Walker Gary Hoff Robert White To those whose names have not been mentioned -- apologies are extended. Take comfort in knowing that you live on in the work that you have wrought. Jon Martin is primarily responsible for whatever technical excellence that exists in RBBS-PC -- including the ability to have multiple RBBS-PC's share the same files. I am not a programmer and didn't even know BASIC until I started writing RBBS-PC and released RBBS-PC CPC10.0 in July of 1983. Jon's commitment to RBBS-PC has at least matched my own. Despite my own Page 11 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 ineptness, Jon's patience, understanding, and technical insights have been unfailing over these several years and, I would like to both publicly acknowledge his contributions to RBBS-PC and express my appreciation for his efforts on behalf of RBBS-PC. I'd also like to mention Ken Goosens' efforts on behalf of RBBS-PC. Ken took the time and trouble to wade through the BASIC source code and incorporated the "security" system that exists within RBBS-PC today. Anyone who looked at the source code prior to release CPC12-2A can appreciate the magnitude of Ken's efforts. I wish space allowed me to chronicle the contributions of each of the contributors to RBBS-PC. In an age of cynicism, RBBS-PC and the Userware concept represents an opportunity for each of us to give back to the world something a little better than when we found it. As I said in section 1, this is something that I believe in strongly. To each of the contributors to RBBS-PC I would like to say personally "I am very proud of the company that RBBS-PC keeps." All changes to RBBS-PC since CPC10.0 have been "ADDITIVE." By that I mean CPC12.5B will run the same way as CPC10.0. I felt that users should not be forced to choose between features (i.e. I can run either the features on CPC11.2 or the features on CPC12.1). 1.4 RBBS-PC Update Conventions ------------------------------- RBBS-PC continues to evolve and be "debugged." The following coding conventions have been helpful in the past and you are requested to observe them in the future: Updates consist of two ASCII files. One called xxxxxx.MOD which are the BASIC source statements for either RBBS-PC.BAS or CONFIG.BAS. The lines that have been modified are indicated as being so modified with a comment beginning in column 70 in the format as follows: 4330 QUICK.SCAN.MESSAGES = FALSE ' CPC131A Because there is no BASIC interperter as yet compatable with the new compilers, unless a modification is only a couple of lines the entire source code of the program must be supplied. The second file is called xxxxxx.DOC which groups each modified line number in xxxxx.MOD into the specific functions added and describes the general feature added or bug that was fixed. Obviously xxxxxx can be anything you wish to name it. The second file will me to integrate several .MOD files and resolve whatever conflicts that may exist. The RBBS-PC naming conventions of CPCxx.x are roughly as follows: 1. If a "bug" is being fixed CPCxx.x will be given a .MOD file name such as CPC13-1A.MOD with a corresponding CPC13-1A.DOC file describing the changes on a line number by line number basis. The first version of CPCxx.x is always "A". When you logon to RBBS-PC the version will be displayed. Page 12 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 2. If a new feature or enhancement is added the last digit in the CPCxx.x will be incremented by one (i.e. CPC12.2D was followed by CPC12.3A). 3. If a significant change to source code or logic occurs, the first two digits of the release level will change (i.e. CPC11.2 was followed by CPC12.0) The purpose of these conventions is to allow everyone to know what RBBS-PC level they are running under (users as well as SYSOPs) and understand the logic behind the changes/fixes as they occur so each SYSOP can evaluate them for his own needs. If you have comments or fixes please let me know so that they can be reflected in the RBBS-PC program and shared with all other users. You can do that by sending your changes by mail to: D. Thomas Mack 10210 Oxfordshire Road Great Falls, Virginia 22066 or uploading the changes to either of my RBBS-PC lines -- (703) 759-5049 or (703) 759-9659. While comments and suggestions are always welcome, those that are accompanied by the RBBS-PC source code changes that implement them carry a lot more weight than those that don't. 1.5 An Example of "Users Helping Users" --------------------------------------- The ability to have multiple RBBS-PC's running concurrently -- either on a single PC in a multitasking DOS environment or in a local area network, is a concrete example of the concept of "users helping users" in action. This ability was developed in support of the efforts of the State of West Virginia Department of Education's "West Virginia Microcomputer Educational Network" project. It is the first statewide microcomputer network and encompasses all of the state's 1,125 schools in 55 different school districts. Each school is intended to have the capability of accommodating up to twenty IBM PC's in a local area network sharing a common 20MB disk drive. As of June of 1984, 83 of the 1,125 schools had such networks. Each PC can communicate with either the LAN, a central library, or with other schools in order to share programs and materials. The key component for this communication is RBBS-PC. In a presentation at the U.S. Department of Education in Washington, D.C.on June 22, 1984, the role RBBS-PC plays was described as follows: "The medium that ties the entire system together -- that allows for communication not only between one school and another but also between schools and the central library -- is an electronic bulletin board (RBBS-PC) This bulletin board will be in operation 24 hours a day at the central site, with a similar bulletin board in operation at every school. The local school bulletin board (RBBS-PC) could be accessed by students who wish to review their lesson or take a test at home provided they had a computer and a modem. Teachers could access their grade book or other reports and lessons at home in preparation for the next school day. Page 13 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 Neither bulletin board system (RBBS-PC) requires personnel to answer telephones or transmit files. They are both totally unmanned and operate 24 hours a day. No toll charges, of course, would be assessed for calling the local school bulletin board and toll free 800 numbers are used for accessing the central library." The State of West Virginia arranged to have the vendors involved, IBM and Corvus, make the appropriate equipment available on a "loan" basis so that RBBS-PC could be developed to work in a local area network environment. Since this project conformed so closely to the primary objectives of RBBS- PC, we agreed to volunteer our time and take on the task of enhancing RBBS- PC to allow up to nine (9) copies of RBBS-PC to execute concurrently sharing many of the same files. On a single PC the maximum number of concurrently running RBBS-PC's within the same DOS is limited only by: a. the number of communications ports installed on the PC. IBM's limit is two (COM1 and COM2), but other vendors supply "add-on" cards which provide for up to eight or more communications ports on a single PC. b. the number of communications ports that the IBM BASIC compiler can read and write to. IBM's limit is two (COM1 and COM2). c. the number of concurrently running tasks that can be supported. IBM's DOS is limited to one task. Other vendors provide "add-on" software to IBM's DOS that provides for up to nine simultaneous tasks. Within a network environment (i.e. multiple PC's linked together sharing the same devices) the maximum number of concurrent RBBS-PC's is set by RBBS-PC's internal design to nine (9). This design was based on the fact that anyone who wanted to run nine RBBS-PC's sharing the same set of files would take the $46,000 needed to buy nine PC's with modems, network interface cards, hard disk (at least 20MB) and purchase a microcomputer for the same amount of money with more ports and storage. For those interested in further information on the State of West Virginia's Microcomputer Educational Network, please contact: Mr. John E. Cook State of West Virginia Department of Education 1900 Washington Street East Building 6, Room 221, Capital Complex Charleston, West Virginia 25305 1.6 What's New with CPC13-1A ---------------------------- CPC13-1A is a complete and total re-write of the earlier versions of RBBS- PC. CPC131-1A must be used in conjunction with it's companion program CONFIG.BAS -- version 1.9. Release CPC13-1A of RBBS-PC reflects the capabilities of the two new BASIC compilers for the IBM PC that were announced in July of 1985. Microsoft announced the QuickBASIC compiler with a suggested list price of $99. International Business Machines Corporation (IBM) announced Version 2 of the IBM BASIC compiler with a suggested list price of $495. Page 14 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 Both compilers are products of Microsoft. QuickBASIC essentially has 95% of the functionality of IBM's Version 2 BASIC compiler. QuickBASIC is 100% compatable with IBM's Version 2 BASIC compiler. When you purchase Version 2 of the IBM BASIC compiler for approximately $400 more than QuickBASIC you get: 1. An .OBJ module librarian. 2. The ability to have arrays larger than 64K. 3. The ability to use indexed files (i.e. ISAM). 4. Two volumes of well written manuals on the BASIC language. 5. The ability to use the Version 1 BASIC compiler's statement "CALL ABSOLUTE". Both products support the full range of capabilities included with Microsoft's BASIC 2.0 Interpreter. RBBS-PC's self-imposed constraint that each version be upward compatable has been extended to be QuickBASIC compatable. This is because QuickBASIC is 100% compatable with IBM's Version 2 of BASIC compiler and because, philosophically, RBBS-PC is founded on the belief that low-cost/high- quality software should be encouraged wherever possible. RBBS-PC version CPC13.1A will run under either the QuickBASIC or IBM's Version 2 compiler. CPC13.1A will not function if compiled using the IBM BASIC Compiler version 1.0, nor will it run under any of the current BASIC interpreters. SYSOPS that do not have access to either of the new compilers can run RBBS- PC version CPC13.1A using the RBBS-PC.EXE and CONFIG.EXE files as distributed and which are available from many RBBS-PC systems around the world. The new compilers relieved RBBS-PC from having to abide by the limitations of the earlier BASIC compiler. In so doing RBBS-PC version 13-1A was able to accommodate many of the enhancements that others had incorporated in their versions of RBBS-PC. These enhancements had not been included in previous version of RBBS-PC primarily becuase they violated the cardinal principle of RBBS-PC -- upward compatability! Essentially what was felt to be the best features within three fundamentally different and incompatable "flavors" of RBBS-PC have been integrated into RBBS-PC CPC13-1A --- Asa Fulton's "X" versions, Mark Seiden's "B" versions, and the .MRG file for RBBS-PC version 12-5B that included the ANSI color and XMODEM/CRC support. Page 15 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 To appreciate the quantum leap that RBBS-PC version CPC13-1A is over the version that immediately preceeded it, CPC12-5B, here are some comparisons: +----------+----------+ | CPC12-5B | CPC13-1A | +-----------------------------------------+----------+----------+ |Release date of RBBS-PC versions | 8/25/85 | 12/1/85 | |-----------------------------------------+----------+----------+ |Lines of source code (RBBS-PC.BAS) | 932 | 6,249 | |-----------------------------------------+----------+----------+ |Size of RBBS-PC.BAS (as an ASCII file) | 67,661 | 218,752 | |-----------------------------------------+----------+----------+ |Size of RBBS-PC.EXE (compiled & linked) | 141,248 | 154,986 | +-----------------------------------------+----------+----------+ The source code provided with CPC13.1A is structured and readable. This is intended to allow stll more enhancements to be incorporated into RBBS-PC by even more SYSOP's. Hopefully such enhancements will reflect the same quality and thoroughness that went into David Terry's XMODEM/CRC merge and documentation files for RBBS-PC version CPC12-5B. 1. The source code for RBBS-PC is now approximately 214K. The reason for this huge growth is that every line was broken so that each statement is on a separate line. Also the two letter variable names have been expanded to readable phrases. Line 842 of CPC12-5B looks like: 842 TV!=(TV!+DAY*ET)*60:CH!=0:GOSUB 4910:CJ#=CJ#+1+SH:GOS UB 24000:GET 1,NC:MID$(R$,1,31)=FNS$(NAM$,31):MID$(R$,57, 1)="A":PUT 1,NC:GOSUB 21996:IF SH THEN 900 ELSE SH=(UG>=S E) In CPC13-1A, line 842 has become: 842 SECONDS.PER.SESSION! = (MINUTES.PER.SESSION! _ + LIMIT.DAILY.TIME * ELAPSED.TIME) * 60 GOSUB 4910 CALLS.TODATE! = CALLS.TODATE! + 1 + SYSOP GOSUB 24000 GET 1,NODE.RECORD.INDEX MID$(MESSAGE.RECORD$,1,31) = FN S$(ACTIVE.USER.NAME$,31) MID$(MESSAGE.RECORD$,57,1) = "A" MID$(MESSAGE.RECORD$,60,4) = BAUD.PARITY$ PUT 1,NODE.RECORD.INDEX GOSUB 21996 IF SYSOP THEN _ GOTO 900 _ ELSE SYSOP = (USER.SECURITY.LEVEL >= SYSOP.SECURITY.LEVEL) IF USER.SECURITY.LEVEL < SYSOP.SECURITY.LEVEL THEN _ GOTO 500 2. Four types of modem control are now supported. 1. The modem will auto answer and RBBS-PC will activate when carrier is present. This will support modems without the "Ring-Detect" signal. Page 16 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 2. The modem will not auto answer and RBBS-PC will activate on the specified number of rings. This is like all the version of RBBS-PC prior to CPC12-5A. 3. Ring-back system for use on non dedicated lines. 4. Dumb modems that auto-answer can now be used. This support allows non-Hayes compatible modems that only can auto-answer to be used with RBBS-PC. The only limitation is that RBBS-PC will be unable to automatically detect the BAUD rate that the user calls in at. Therefore the speed at which the modem is initialized, as selected in RBBS-PC's CONFIG program, will be the only BAUD rate RBBS-PC will recognize with this type of "dumb" modem. 3. DOS 2.x and abouve sub-directories can be used for downloads and uploads. RBBS-PC can handle a maximum 99 DOS sub-directories. 4. Based on the option the SYSOP selects in RBBS-PC's CONFIG program, a SYSOP may elect to restrict access to 1200 Baud and higher and deny access to 300 BAUD callers. 5. RBBS-PC now allows the SYSOP to see the color menus on the color monitor connected to the PC that is running RBBS-PC in the same manner as they are presented to the remote user. This requires that the ANSI.SYS supplied by IBM be included in the system's CONFIG.SYS file and that Fred Clark's and Dave Staehlin's ANSI.OBJ be included in the RBBS-PC link step. This option is activated by selecting it within RBBS-PC's CONFIG program. 6. Extended CALLERS file logging can be selected from RBBS-PC's CONFIG program. The additional disk storage required for Extended Logging is only worthwhile if you will be using a program to analyze the CALLERS file that recognizes the new entries (such as Call Analyzer version 3.6C). Extended logging includes: 1) "Connect not completed" 2) "Sleep disconnect" 3) "Caller changed name/address" 4) "Newuser" 5) "Bulletin# read" 6) "Sysop initiated Chat" 7) "Entered Conference name" 8) "Time limit exceeded" 9) "Left comment at time" 10) "Logged off at time" 7. CPC13-1A now provides the SYSOP to have a "PRELOG" file. It must reside on the same drive as the "welcome" file. If the file is present the user will be presented the file prior to determining 300 BAUD access allowed and before being asked the users First Name. This allows the sysop to inform 300 BAUD callers why they are disconnected or that "REAL NAMES" are required etc. Page 17 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 8. CPC13-1A no longer requires UTILITY.OBJ to be linked with RBBS-PC.OBJ since the new compilers provide the functions that UTILITY was being used for. 9. CALL ABSOLUTE is not valid in the QuickBASIC compiler. Therefore a new RBBSML.OBJ must be added to the RBBS-PC link step. 10. David Terry's Xmodem CRC for file transfer are now supported and XMODEM.OBJ is required in the link step. 11. The SYSOP function key screen at initialization now identifies if: 1) 300 BAUD access not allowed 2) Color support activated 3) Extended logging activated 4) Modem waiting for carrier 5) Modem waiting for ring detect 6) Ringback activated 12. The time in CHAT is no longer charged against the users allocated time for the session. 13. Welcome screens have been added for conferences. The format is the conference name + W.DEF. The file is a text file created by your favorite word processor. If a matching welcome file does not exist RBBS-PC will continue with no error messages. 14. For non-networked systems the "UM UU UB UD" on line 25 of the SYSOP screen is replaced by the time a user logged on. 15. The security level of the current user is now displayed on line 25 in front of their name. 16. The SYSOP can now select the action to be taken by RBBS-PC when a DISK FULL condition occurs. 17. The drive ID from which RBBS-PC loads COMMAND.COM must be provided via RBBS-PC's CONFIG program. This was necessary for networks that use different versions of DOS from different computer types. 18. The F2 key usage was changed to give the local SYSOP the ability to drop to DOS while a user is online. Control is returned to the user when the SYSOP returns from DOS. RBBS-PC drops to DOS for the local SYSOP by using the SHELL command and the SYSOP return from DOS by issuing the EXIT command. 19. The W)ho's on the other nodes was enhanced to show the BAUD rates of the users on the other nodes. This will help explain to a user why the system has slowed down when running in a multi-tasking environment. 20. Word wrap has been added to the CHAT function. This automatic function will move split words down to the next line and continue the chat. 21. All references to C/R have been replaced by [ENTER] hopefully this will keep new users from typing C/R instead of just pressing the ENTER key. Page 18 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 22. All the prompts to the user have been expanded to make RBBS-PC a more friendly system. 23. Users can now join a conference directly from the main menu. This is accomplished by stacking the J)oin command and the name of the conference at the main menu prompt (i.e. J;BETA101). 24. A user can also join a conference with one command from the conference menu. This is accomplished by stacking the J)oin command and the name of the conference at the conference menu prompt (i.e. J;BETA101). 25. When entering a message CHR$(11) and CHR$(12) are screened out and are not allowed. This will keep users from having RBBS-PC do unusual things with the local display. 26. Now a user calling back will be given a Welcome back message. This is like the older versions of RBBS-PC. 27. Because the Microcom library code was generated by the Lattice C compiler, and because the Lattice C compiler makes assumptions about how data segments are loaded in memory that are incompatible with the way the LINKer supplied with the QuickBASIC compiler, MNP is regretably unavailable with RBBS-PC version CPC13-1A. Hopefully this is only temporary. 28. When a remote SYSOP makes a temporary password change is is now recorded as "********". 29. All the modem commands are external to RBBS-PC.BAS and are included in the RBBS-PC.DEF file. This file can be edited by any editior (i.e. EDLIN) and these commands can be changed to reflect the requirements of the particular modem that is being used with RBBS-PC. Page 19 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 2.0 RBBS-PC "BASE-LINE" HARDWARE REQUIREMENTS --------------------------------------------- RBBS-PC CPC13-1A is designed to run on an IBM Personal Computer running IBM's Disk Operating System (DOS), communicating via an IBM Asynchronous Communications Adapter and a Hayes Smartmodem modem. For RBBS-PC CPC13-1A the following equipment and software is the MINIMUM recommended: IBM PC 80 column monitor Asynchronous communications adapter (serial port) Hayes Smartmodem (or 100% Hayes compatible!) Voice grade telephone connection for modem 25 pin RS-232-C modem cable (for stand alone modem) 192K RAM Two double-sided drives PC-DOS 2.0 or higher RBBS-PC can be run in either a single double-sided drive or two single- sided drive configuration. However, the less disk space available the more file maintenance the SYSOP must do. The majority of RBBS-PC systems utilize hard disks primarily because the price of such devices have become so low (i.e. a 10MB internal drive can cost as little as $400). If you have a second telephone installed specifically for RBBS-PC, ask for a second voice grade telephone line. Data lines are very expensive and are not necessary. The program requires the use of a Hayes Smartmodem (or one that is 100% Hayes compatable) in order to function properly. If your non-Hayes modem doesn't work with RBBS-PC, send RBBS-PC (source code and all) to the vendor and ask him to expalin why it doesn't work (i.e. why it is "incompatable" with the Hayes smartmodems). Callers who come in at even parity and 7 data bits, then try to change to no parity and 8 data bits to use XMODEM, may have a problem if they are using PC-TALK and a Hayes Smartmodem. Switch 1 on the caller's modem has to be down (the factory default position) or the carrier will be dropped when the communication parameters are switched. To avoid this the PC-TALK caller will have to enter the escape code (factory setting "+++"), reset the modem parameters with Alt-P and/or Alt-F, and then return to the "connect" state with the command "ATO." Callers who wish to communicate at 450 baud have to call in at 300 baud then switch to 450 using the N)ew baud selection from the "Utilities" menu. Beginning with version CPC12-5B, RBBS-PC does not require PIN 22 to be hooked up on the RS-232-C cable (that's the cable which runs between the modem and the computer). If you specify in option 9 of CONFIG that RBBS-PC is to answer the phone on a specified number of rings (and that it is not a RING-BACK system), RBBS-PC will initialize the modem so that the MODEM automatically answers the phone. Otherwise the default with CPC13-1A is that RBBS-PC depends on PIN 22 to know when the phone is ringing and RBBS- PC (NOT the modem) answers the phone. In order for RBBS-PC to answer the phone on a specified ring number, the modem must send a "ring-indicator" signal to to RBBS-PC. This is the way that RBBS-PC detects that the phone is ringing. Some computers (i.e. the PCjr's external RS232 interface) and some modem cables don't have a "ring- indicator" signal. PIN 22 is the ring indicator coming from the modem Page 20 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 going to the computer. Just because you bought an RS232 cable, don't assume that it has PIN 22 connected. The $55 12-pin RS232 cable sold by many computer stores often may not have PIN 22 connected. For about $18 in parts from Radio Shack you can put together your own RS232 cable with all the pins connected. Recently a friend of mine paid $14.88 (including postage) for a RS232 cable with all the pins connected by ordering part number CDB25P-4-S from Jameco Electronics. Jameco Electronics' telephone number is (415) 592-8097. Page 21 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 3.0 RBBS-PC's Support Policies ------------------------------ 3.1 RBBS-PC's Vendor Support Policy ----------------------------------- The only reason RBBS-PC is "hardware-specific" to the IBM PC and the Hayes Smartmodem is that these have pretty much set an industry standard (let's not debate the issue of whether they have also set a "technology" standard). If you follow the code in RBBS-PC closely, you will notice that a great deal of effort was expended in order not to be "hardware-dependent" on either the Hayes or the IBM PC. The purposes of RBBS-PC are outlined in section 1.0 of the RBBS-PC documentation. Those who contribute to RBBS-PC do so without any hope of monetary reward. In fact, great lengths are taken to assure that neither those involved with the development of RBBS-PC nor anyone who distributes RBBS-PC does so for either personal gain or to promote a specific product at the expense of other products. If the hardware you are using is not part of the "base-line" hardware and RBBS-PC doesn't work, your only recourse is to either modify RBBS-PC to meet your particular hardware's needs (that's why the source code is distributed) or contact your vendor and ask him to fix his hardware or modify RBBS-PC (via .MOD/.DOC files) to support his hardware. Since 1984 RBBS-PC became something of an "industry standard." As such several manufacturers have requested that support for their particular hardware and/or software be incorporated into RBBS-PC. These vendors have had three choices: 1. Obtain a copy of the BASIC source code by sending $8 to the Capital PC User Group's Software Exchange. The source code allows the vendor to determine what is required to be "RBBS-PC compatible." Who better knows the quirks of the manufacturer's product than the manufacturer? RBBS-PC's limited license specifically permits the distribution of ".MOD" files that would allow RBBS-PC to run with whatever idiomatic quirks a specific vendor's product exhibited. The advantage to the manufacturer is that he is in complete control and need not make the .MOD "universal" (i.e. it need only support his product). The disadvantage is that new releases of RBBS-PC come out every six to eight weeks and the vendor would have to review each release to make sure the new releases and his .MOD files were compatible. Of course, as with any other RBBS-PC operator, casual telephone support is available to these vendors. 2. Supply the necessary equipment or software on a loan or gift basis to be used in the testing of future releases of RBBS-PC. This approach has been actively DISCOURAGED for three fundamental reasons. First, the vendor perceives he has "paid" for on-going support by the loan or donation of the product. This is not the case because RBBS-PC's development is an all-volunteer activity. As such, neither I nor any of the others involved with the development of RBBS-PC may have the time nor expertise sufficient to assure compatibility of the specific vendor's product with future Page 22 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 releases of RBBS-PC. About all that can be done is to give the vendor our "best effort" to assure compatibility, and advise when it can not be made compatible. Second, the particular product may not have a universal applicability to RBBS-PC users and (or) may not be of interest to those who regularly contribute to the development of RBBS-PC. Both of these conditions must exist before any vendor's product is incorporated into the RBBS-PC development cycle. Third, the price of the loaned or donated products (usually 3 to 5 such products) in no way can even begin to compensate for the hundreds (if not thousands) of development hours required to support other than "base-line" hardware. 3. Establish an on-going institutional commitment to maintain a dialogue between the vendor's engineering group and the RBBS-PC development team along with supplying the necessary equipment or software on a loan or gift basis to be used in the testing of future releases of RBBS-PC. This approach has been actively ENCOURAGED for three different and fundamental reasons. First, the vendor overtly makes an institutional commitment to jointly participate in the development of RBBS-PC. The vendor has the opportunity to supplement the all-volunteer activity that is the basis for RBBS-PC development by choosing to either modify their current or future products to be compatible with RBBS-PC or to supply software that ensures compatibility with RBBS-PC. This benefits all RBBS-PC users. Second, the particular products that fall into this category are required to have a universal applicability to RBBS-PC users (i.e. multi-tasking DOS, networking, 2400 or greater baud capability, error-free protocols, etc.). Also a regular contributor to RBBS- PC's development must be geographically located close to the vendor's development engineers to assure a timely dialogue. Further any regular contributor to RBBS-PC's development who accepts the responsibility for assuring RBBS-PC's compatibility with a particular vendor's product must be willing to do so solely on a volunteer basis over an extended period of time and in such a way as not to exclude other vendor's products. Only when all these conditions exist is any vendor's product a candidate to be incorporated into the RBBS-PC development cycle. This assures that the RBBS-PC user community has a feed-back mechanism to the vendor's product development and design teams and the vendor is assured of a matching long-term commitment from the RBBS-PC development team. Third, the vendor recognizes that the price of the loaned or donated products (usually 3 to 5 such products) is minuscule compared with the hundreds (if not thousands) of man-hours that may be required from both the RBBS-PC development team as well as the vendor's engineers. This assures that the vendors who choose this third approach are committed to the PC user community. It is precisely this type of commitment that RBBS-PC's USERWARE concept is designed to encourage (from both users and vendors) Page 23 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 Vendors who have chosen to make this third type of commitment to RBBS-PC and the PC user community deserve the respect and encouragement of every PC user and are (alphabetically): Ark Electronic Products, Inc. 325 W. Hibiscus Blvd. Melbourne, Florida 32901 (305) 724-5260 Corvus Systems, Inc. 2100 Corvus Drive San Jose, California 95124 (408) 559-7000 Hayes Microcomputer Products, Inc. 5923 Peachtree Industrial Blvd. Norcross, Georgia 30092 (404) 449-8791 International Business Machines Corporation (Internal Zip Code 2900) P.O. Box 1328 Boca Raton, Florida 33432 (305) 998-2000 Microcom, Inc. 1400A Providence Highway Norwood, MA 02062 (617) 762-9310 Multi-Tech Systems, Inc. 82 Second Avenue, S.E. New Brighton, Minnesota 55112 (612) 631-3550 Orchid Technology 4790 Westinghouse Drive Fremont, CA 94539 (415) 490-8586 Prometheus Products Incorporated 4545 Cushing Parkway Fremont, CA 94538 (415) 490-2370 Racal-Vadic 1525 McCarthy Blvd. Milpitas, California 95035 (408) 774-0810 The Software Link, Inc. 8601 Dunwoody Place Suite 336 Atlanta, GA 30338 (404) 998-0700 Page 24 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 Users who feel that they have benefited or who appreciate such commitment to the user community should write or call the above vendors and tell them so, especially if such a commitment influenced the purchase of their products. Similarly, if any user feels that other vendor should make a similar commitment to RBBS-PC and the user community, write to that vendor and send a copy of your letter to the following address: D. Thomas Mack 10210 Oxfordshire Road Great Falls, Virginia 22066 APPENDIX B describes the RBBS-PC specifications for those vendors of proprietary protocols who would like to have them added to future releases of RBBS-PC. 3.2 RBBS-PC's User Support Policy --------------------------------- RBBS-PC is an all-volunteer effort on my part. Professionally I am not a programmer (as anyone who has looked at the source code can testify) nor an "expert/guru" on personal computers. Since I am not independently wealthy, I have a full time job (unrelated to PC's). As with most other folks, I'm also busy raising a family. What time I can spare from these other activities I am glad to donate to answer questions about RBBS-PC as I believe (somewhat fanatically) in the Userware concept. However, if you have questions regarding something other than the "base- line" hardware and software requirements outlined in section 2.0, DON'T CALL ME. I probably can't help you anyway and even if I do venture some advice it will probably be wrong. One of the axioms of the "Userware" concept is that every user should be able to help themselves -- that's why there are 108 pages of documentation and the source code is distributed. The only calls that I truly appreciate are those that reveal BOTH a problem and a solution. These I am more than happy to share with anyone and are included in RBBS-PC (either the documentation, the software, or both) as rapidly as possible. Of course, if you encounter a problem and 1. read and re-read the documentation, 2. spend days and days attempting to isolate it, 3. called other SYSOP's and asked their help, 4. looked up any error messages you encountered (they are in the BASIC manual that comes with your IBM PC's DOS), 5. know what version of RBBS-PC that you are running, 6. know what version of CONFIG that you are running, 7. eliminated all other software from your environment, and still can not get RBBS-PC to work, I am most happy to lend whatever telephone advice I can. In this regard, it may help to remember that there are only two types of problems -- MY problems (which are the ones that I can solve) and OTHER PEOPLE's problems (which are the ones that I can't solve). Page 25 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 4.0 OPERATING SYSTEM REQUIREMENTS --------------------------------- Beginning with RBBS-PC version CPC13-1A, RBBS-PC requires version 2.0 or above of IBM's Disk Operating System (DOS). RBBS-PC will not run under the BASIC interpreter. Nor is it reasonable to expect that RBBS-PC would run under ANY other DOS supplied by any other vendor (including Microsoft). Page 26 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 5.0 HOW TO GET A COPY OF RBBS-PC SENT TO YOU -------------------------------------------- RBBS-PC can be obtained by sending a check for $8 to the Capital PC Software Exchange P.O. Box 6128 Silver Spring MD 20906. RBBS-PC is distributed on two double-sided, 9-sector, diskettes. Allow 3 to 4 weeks for delivery -- remember this is an all-volunteer effort. Be sure to specify RBBS-PC CPC13-1A on "diskette # 18". The exigencies of RBBS-PC software releases may mean that diskette 18 contains an earlier version of RBBS-PC than CPC13-1A (either you bought diskette 18 sometime ago or there has been not enough time for diskette 18 to be updated to this most current version). Not to fear! Your $8 has not been wasted. At least two bulletin boards keep the most current copies of RBBS-PC CPC13-1A for downloading. They are: (703) 759-5049 --+ +---- East Coast (Great Falls, Virginia), (703) 759-9659 --+ (415) 689-2090 ------- West Coast (Concord, California). Page 27 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 6.0 FILES RBBS-PC USES ---------------------- There are essentially two types of files that RBBS-PC uses -- "system" and "text" files. "System" files are defined as random files that RBBS-PC reads and writes to. "Text" files are defined as files that RBBS-PC primarily reads from. Text files can be edited externally to RBBS-PC with most text editors that can handle ASCII files. Either type of file can be "static" or "variable" in length. By "static" it is meant that these files have a pre-defined length beyond which RBBS-PC does not extend them. Similarly, "variable" length files are defined as those files whose length is dynamically increased by RBBS-PC. In a multiple RBBS-PC environment only the "static" length files can be shared SAFELY among the various RBBS- PC's. The following table summarizes, using the default file names, which categories the various RBBS-PC files fall into: "Static" Length Files "Variable" Length Files ----- /|\ MESSAGES CALLERS System USERS COMMENTS Files MESSAGES.BAK 99.DIR (upload directory) \|/ USERS.BAK upload disk ----- RBBSxPC.DEF ----- BULLET /|\ BULLET1 --> BULLETn | DIR.DIR | aa.DIR --> bb.DIR Text FILESEC and PASSWRDS Files HELP01 --> HELP08 | MENU1 --> MENU5 | NEWUSER | PRELOG \|/ TRASHCAN & CONFENCE ----- WELCOME In a CORVUS network environment some of the "static" length files can be shared on a common volume and ALL of the "variable" length files must be segregated on volumes unique to each copy of RBBS-PC. RBBS-PC issues the NAME function of BASIC in order to determine if a file exists. Because of this, all the volumes accessed by any RBBS-PC in a CORVUS network must be designated "read/write." Therefore, you must be very careful when running CONFIG.BAS. CONFIG creates the definition file (RBBSxPC.DEF) for each copy of RBBS-PC. In a CORVUS network you should arrange the location of the RBBS-PC files as follows: Shareable RBBS-PC Files in a Non-shareable RBBS-PC Files in a CORVUS network (i.e. on a CORVUS network (i.e. each RBBS-PC common volume) has a volume dedicated to it) ----- CALLERS /|\ MESSAGES COMMENTS System USERS 99.DIR (upload directory) Files MESSAGES.BAK upload disk \|/ USERS.BAK RBBSxPC.DEF ----- Page 28 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 Shareable RBBS-PC Files in a Non-shareable RBBS-PC Files in a CORVUS network (i.e. on a CORVUS network (i.e. each RBBS-PC common volume) has a volume dedicated to it) ----- /|\ BULLET | BULLET1 --> BULLETn | DIR.DIR | aa.DIR --> bb.DIR Text FILESEC and PASSWRDS Files HELP01 --> HELP08 | MENU1 --> MENU5 | NEWUSER | PRELOG \|/ TRASHCAN & CONFENCE ----- WELCOME In a MultiLink (from the Software Link, Inc.) environment and in Orchid's PC-NET environment the vendors claim that not only all the "static" length files can be shared on a common volume but also some of the "variable" length files can be shared. However, if you want to be as conservative as possible, run RBBS-PC in ALL environments as if it where running in a CORVUS network environment. However, if you rely on the vendors claims, in either a MultiLink or PC-NET environment, when running CONFIG.BAS which creates the definition file (RBBSxPC.DEF) for each copy of RBBS-PC, you must be careful to arrange the RBBS-PC files as follows: Shareable RBBS-PC Files in a Non-shareable RBBS-PC Files in a MultiLink or PC-NET enviro- MultiLink or PC-NET environment nment (i.e. shared on a (i.e. each RBBS-PC has a volume common volume) with these files dedicated to it) ----- /|\ MESSAGES, MESSAGES.BAK CALLERS | USERS, USERS.BAK System COMMENTS Files 99.DIR (upload directory) | upload disk \|/ RBBS-PC.DEF ----- ----- BULLET /|\ BULLET1 --> BULLETn | DIR.DIR | aa.DIR --> bb.DIR Text FILESEC and PASSWRDS Files HELP01 --> HELP08 | MENU1 --> MENU5 | NEWUSER | PRELOG \|/ TRASHCAN & CONFENCE ----- WELCOME Page 29 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 6.1 RBBS-PC System Files ------------------------- As shown above, "system" files are both static and variable in length. The system files used by RBBS-PC are: MESSAGES - This file is a random file that contains the message text for the RBBS-PC system. The first record in the file contains the RBBS-PC "checkpoint" record. The records immediately following this first record are the RBBS-PC "node" records. The rest of the file consists of message header records which are followed by the message text for that header. Appendix A describes the fields and their uses within the various type of records of the messages file. RBBS-PC expects the MESSAGES file to exist and to have been created by CONFIG.BAS. If CONFIG.BAS does not find the MESSAGES file or it finds one in pre-CPC12-3A format, it will create it and initialize it to the size the SYSOP specifies. Because of the fixed length records in this file, it should not be created or edited outside RBBS-PC. When the SYSOP "packs" the message file using CONFIG.BAS, the file MESSAGES.BAK is created to hold the old messages in case the "pack" is unsuccessful (i.e. not enough space to duplicate the message file). If the disk fills up during the pack function RBBS-PC will recover the message file using MESSAGES.BAK. When the messages file is successfully packed, the pre-packed messages file is renamed MESSAGES.OLD and the temporary file MESSAGES.BAK is renamed MESSAGES. The MESSAGES file should only be "packed" in a multiple RBBS-PC environment when there are no RBBS-PCs active. The MESSAGES file can be shared among multiple RBBS-PCs. USERS - The USERS file is a random access file that has a record for each user who used the system. The record contains a profile for each user who has logged onto RBBS-PC. Appendix A describes the format of the records within the USERS file. The records are 128 bytes in length and are automatically maintained by RBBS-PC. The SYSOP can do some limited editing using SYSOP function 5. To initialize the system simply ERASE this file. RBBS-PC expects the USERS file to exist. If CONFIG.BAS does not find the file on the system it will create it to the size specified by the SYSOP. The USERS file should not be created or edited outside CONFIG.BAS. When the SYSOP "packs" the user file using CONFIG.BAS, the file USERS.BAK is created to hold the old users in case the "pack" is unsuccessful (i.e. not enough space to duplicate the users file). If the disk fills up during the pack function RBBS-PC will recover the USERS file with USERS.BAK. When the users file is successfully packed, the pre- packed users file is renamed USERS.OLD and the temporary file USERS.BAK is renamed USERS. The USERS file should only be "packed" in a multiple RBBS-PC environment when there are no RBBS-PC's active. The USERS file can be shared among multiple RBBS-PC's. CALLERS - This file is a random file that contains a log of all callers as they log on to the system along with callers city and state, the date and the time. The names are added to the end of the file as well as are the names of the files uploaded/downloaded by the caller. If the file is not found RBBS-PC will create a new one. The file should be ERASED to clear the log. The CALLERS file cannot be shared among multiple RBBS-PC's. COMMENTS - This file is a sequential file that contains any comments that have been left by users for the SYSOP. The file can be scanned by a SYSOP function or it can be TYPEd or edited outside the RBBS system. A SYSOP Page 30 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 function is available to delete this file, or it can be emptied outside of DOS. The file will be created by RBBS-PC if it is not found. The COMMENTS file cannot be shared among multiple RBBS-PC's using CORVUS's "OMNINET". This file can be shared using MultiLink or Orchid. 99.DIR - The file on the upload disk that is to have the name, file size, date, and description appended to it of files that have been uploaded. The 99.DIR file cannot be shared among multiple RBBS-PC's using CORVUS's "OMNINET", but can be shared using MultiLink or Orchid. RBBS-PC.DEF - This is an ASCII text file created as output by the CONFIG.BAS file. It contains the configuration parameters for the RBBS. It is read by RBBS to determine the configuration settings tailored to your RBBS- PC. In a multiple RBBS-PC environment the definition file for each RBBS-PC is named RBBSxPC.DEF where "x" is a number 1 through 9 , 0 (for the tenth copy), and A through Z (for the eleventh through 36th copy) corresponding to which copy RBBS-PC it describes. In a multiple RBBS-PC environment, (i.e. using "OMNINET") each RBBS-PC should have a unique volume that the other RBBS-PC's should not write to (they may read from) on which to write it's CALLERS, COMMENTS, 99.DIR, RBBSxPC.DEF, and file uploads. In an "OMNINET" network with four RBBS- PC's, the disk volumes would all have to allocated as both read and write. The SYSOP would have to set up each RBBSxPC.DEF file carefully using CONFIG.BAS such that the actual access was as follows: Physical Physical Physical Physical Physical Volume "D" Volume "E" Volume "F" Volume "G" Volume "H" RBBS-PC #1 READ/WRITE Read-only Read-only Read-only Read-write RBBS-PC #2 Read-only READ/WRITE Read-only Read-only Read-write RBBS-PC #3 Read-only Read-only READ/WRITE Read-only Read-write RBBS-PC #4 Read-only Read-only Read-only READ/WRITE Read-write Physical volume "H" would contain all the shareable RBBS-PC files. The files that are "shareable" are a function of the type of environment that the multiple RBBS-PC's are running in (see section 6.0). Each copy of RBBS-PC would have it's own physical volume that all the other copies of RBBS-PC would access as "read-only" and which it could access as "READ/WRITE." This "READ/WRITE" volume would contain all the non-sharable RBBS-PC files. The files that are "non-sharable" are a function of the type of multiple RBBS-PC environment that RBBS-PC is running in (see section 6.0). RBBS-PC displays on line 25 the status of those files which must be locked in a network environment. The lock status of the message file is displayed in positions 68 & 69. The lock status of the user file is displayed in positions 71 & 72. The lock block status is displayed in positions 74 & 75 and comments/uploads share positions 77 & 78. The letter "U" in the first position shows that the file is currently "UNLOCKED". The letter "L" in the first position indicates that the file is "LOCKED". Page 31 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 6.2 RBBS-PC Text Files ----------------------- Similarly, the RBBS-PC "text" files are both static and variable in length. The "text" files used by RBBS-PC are: BULLET - This is a text menu file that is printed following the WELCOME file when a user first enters the system. It must be present if "CONFIG Utility parameter # 43" is greater than 1. It can also be called from the main menu with the <B>ulletins command. BULLET1 --> n -- There can be 1 to 99 "bulletins". RBBS-PC will check for the existence of a file whose name consists of the prefix given by parameter 44 of CONFIG.BAS appended with the bulletin number and using parameter 41 of CONFIG.BAS to determine the drive to find the bulletin on. Users can elect to have displayed two different types of "graphics" files for such standard RBBS-PC system files as HELPxx, BULLET, MENU's, etc. In order for a user to see either of these two different types of "graphics" files, the following must have occured: logged on N/8/1, requested graphics (either full ASCII or "color/music"), and the file must exist and the filename end in either: "G" for files containing the graphic ASCII characters whose values are in the range 129 to 256, or "C" for files containing combinations of the full 256 characters that the caller's communication software can interpert and translate into colors and music (i.e. PCTK666, QMODEM, and EXECPCT). RBBS-PC will check to see if a "graphics" files exists by appending a "G" or "C" to the file name. If such a file can't be found, RBBS-PC will check to see if a non-graphics file exists (i.e. one without the "G"). RBBS-PC will display the first file it finds or a message that the file can not be found. DIR.DIR, aa.DIR --> nn.DIR -- At least one DIR.DIR file has to be present on one of the drives available for downloading. Alternative directories, aa.DIR --> nn.DIR (see section 9), should be meaningful and should be reflected in the DIR file. FILESEC - is more fully described in section 12.4 on security. HELP01 --> HELP09 -- Represent the nine on-line help files for RBBS-PC users. They are associated with the following areas: HELP01 -text file that is printed when <H>elp is requested on the main function prompt. It contains command information. HELP02 -text file that is printed when a <?> is entered on the main function prompt. It is also printed following the NEWUSER file for new users and tells users what functions the RBBS supports. HELP03 -text file that describes the message protection options when <?> is entered after the message <E>nter command is executed at the main message menu. Page 32 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 HELP04 -text file that describes the message entry subfunctions when <?> is entered at the subfunction prompt. HELP05 -text file that is printed when <H>elp is entered in the files subsystem function prompt. HELP06 -text file that is printed when a <?> is entered in the files subsystem function prompt. HELP07 -text file printed when <H>elp is requested at the message read prompt. HELP08 -text file printed when <H>elp is requested in the utility subsystem function prompt. HELP09 -text file printed when <H>elp is requested for type of graphics a user wants (none, ASCII, color/music). MENU1->5 -- contain the various commands for the subsystems. It is recommended that these be placed on an electronic disk drive (i.e. RAM) rather than on a floppy or hard drive. NEWUSER - This is a text file that is displayed for new users just before registration occurs. PASSWRDS - is more fully described in section 12.3 on security. PRELOG - This is a text file that is displayed when a user dials up but before he can log on. TRASHCAN - is a text file that contains names that the SYSOP finds objectionable and does not want used as either a users first or last name. RBBS-PC uses this file, if it exists, to deny access to anyone using one of these names for either their first or last name. WELCOME - This is a text file that is printed when a user first enters the system. It must be present, and it should be modified to identify your system. Similarly each "confernce" can have a "welcome" file by having a file whose last charcter ended in a "w" (i.e. conference "RBBS" would have a message file named RBBSM.DEF and a user file named RBBSU.DEF if it where a "private" conference and a welcome file named RBBSW.DEF). CONFENCE - This is a text file that is printed when a user selects the J)oin function from the main menu. It should be created using your favorite text editor and should contain a list of the conferences that you have on your system. Page 33 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 7.0 USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC CPC13 --------------------------------------------------------- The RBBS-PC.DEF file you get (which, if you don't have it originally, is created for you by the CONFIG.BAS program) contains the program's default operating parameters and values. When you run the CONFIG.BAS program to create RBBS-PC.DEF or to update it, you can change many of these parameters to meet your needs. Certain parameters which control critical operations of the programs are embedded in the RBBS program and should not normally be changed by the system operator. Unless a value or parameter is noted here, it should be changed only with great forethought and caution. CONFIG.BAS, unlike Gaul, is divided into nine parts or screens. They are: Screen Description 1 Global RBBS-PC Parameters (Part 1 of 2) 2 Global RBBS-PC Parameters (Part 2 of 2) 3 Parameters for RBBS-PC "text" files 4 Parameters for RBBS-PC "system" files 5 Parameters for RBBS-PC "doors" 6 Parameters for RBBS-PC Security 7 Parameters for Multiple RBBS-PC's and "conferences" 8 RBBS-PC Utilities 9 Use of Dos Subdirectories The user may scroll forward or backward through the 9 screens of parameters in CONFIG.BAS using the PgUp and PgDn keys on the keyboard. Additionally users may go directly to a specific screen by pressing a function key (F1 through F9) coressponding to the page to be selected. To terminate CONFIG, users need only press the "End" key on the keyboard. The compiled version of CONFIG.BAS can be invoked with the command: CONFIG.EXE This assumes that the compiled version of CONFIG.BAS, CONFIG.EXE is on the default disk drive. CONFIG.BAS will write the RBBS-PC definition file, RBBSxPC.DEF to the default drive. 7.1 Global RBBS-PC Parameters (Part 1 of 2) ------------------------------------------- 7.1.1 SYSOP's Name and Password for Remote Access ------------------------------------------------- Parameters 1-4 request the RBBS system operator's (SYSOP) name and dual passwords. When logging onto the system remotely, the SYSOP can log on using Password #1 as a first name and Password #2 for as last name, in which case the system will recognize them as the SYSOP and allow all the SYSOP functions to be preformed, even as a remote user. The SYSOP name is used to insure that users are not attempting to access RBBS-PC using the SYSOP name hoping to get a higher access level. Attempting to logon using the SYSOP name will result in "LOGON DENIED" and a posting of the attempt in the CALLERS file. If you want to eliminate anyone from logging on as the SYSOP, you can simply reply with a "null" (i.e. a carriage return) to Password #1 and Password #2. Page 34 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 7.1.2 Password to Take Over RBBS-PC Locally as SYSOP ---------------------------------------------------- The ESC key is used to log on in local SYSOP mode. Parameter 5 allows a password to be required if someone hits Esc on the keyboard of the PC running RBBS-PC before they are considered a local SYSOP. If you enter NONE, no password is required. 7.1.3 SYSOP's default sign-on mode ----------------------------------- Parameter 6 sets the system operator's sign-on mode as EXPERT or NOVICE. Unless you are very familiar with the RBBS-PC CPC13's command structure, the SYSOP's sign-on mode should be NOVICE. 7.1.4 SYSOP's "office" hours ---------------------------- Parameter 7 is for the SYSOP's "office hours" (i.e. when the SYSOP can be paged by a user). The IBM PC's bell is rather insistent, and these hours should be set to match when you will be within ear-shot of the RBBS-PC. The times are set using a 24-hour military clock (i.e. 10:00 P.M. is 2200 hours). NOTE: These hours can be overridden by activating the page bell (F4). 7.1.5 Use of Printer Bell ------------------------- Parameter 8 allows allows the SYSOP to elect to have the bell on the printer sounded (it is usually louder than the PC's) when he is being "paged". 7.1.6 Number of Rings RBBS-PC Waits Before Answering ---------------------------------------------------- Parameter 9 specifies the number of rings to wait before answering the phone. Specifying zero rings means that RBBS-PC will answer the phone as soon as it rings. If you specify the number ONE RBBS-PC will wait for the phone to ring and then instruct the modem to answer the phone. This is the default setting and requires that the modem be capable of indicating that the phone is ringing (i.e. provide the "ring indicator" signal) and that the modem cable have PIN 22 connected at both ends. Specifying a number equal to ZERO (and not specifying "ring-back") means that RBBS-PC will initialize the modem to automatically answer the phone (independent of RBBS-PC) and RBBS-PC will simply wait for carrier detect to occur. This is NOT RECOMMENDED. Howeve, if your non-Hayes modem simply is incapable of indicating that the phone is ringing or your modem cable does not have PIN 22 connected, this is the option you will have to elect. If this option is selected, do not drop into DOS remotely (either through a "door" or via the SYSOP's function 7). If you do and are inadvertently disconnected the next person to dial will be connected to wherever you where because the modem (not RBBS-PC) is answering the phone. If you specify a number greater than 2 means that RBBS-PC will either: 1. wait until the specified number of rings to answer the phone, or Page 35 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 2. answer the next call after the current one after the specified number of rings specified provided that the next call comes within 45 seconds after the first call stops ringing the phone. This mode is called RING-BACK. Specifying a number greater than one is useful only when a single phone line can receive both voice (i.e. callers who wish to speak with the SYSOP) and data calls (i.e. for RBBS-PC) on an unscheduled basis. In this type of environment (i.e. a random mix of voice and RBBS-PC calls), there are two ways a SYSOP can set up RBBS-PC so that RBBS-PC can automatically determine if the call is for the SYSOP or for RBBS- PC. First, the SYSOP can establish the rule with the callers that if unable to personally answer the phone, then RBBS-PC will answer the phone after it rings the number of times specified in option 9. Callers can let the phone ring and (if it is not answered by a person within some agreed upon number rings) know that it will be answered by RBBS-PC. This is useful to those who may have either hearing or speech problems and are unable to use the telephone conveniently for voice communications. A second approach is the more classic, "ring-back" approach. RBBS-PC can be told to NEVER answer the first call (it can ring forever!). However, should the caller WAIT A MINIMUM OF 12 SECONDS (a Hayes restriction) and call back no later than 45 seconds after the last ring of the first call, RBBS-PC will answer the call after the number of rings indicated in parameter 9 provided that the number of rings is set to between one and five. If callers want to make a voice contact, they can simply call and let the phone ring until it is answered. If you have a dedicated line for your RBBS-PC (either full-time or on a scheduled basis), parameter 9 should be set to ZERO. 7.1.7 Deny Access to Callers Who Use 300 Baud --------------------------------------------- Parameter 10 allows a SYSOP to not accept calls if the caller is trying to access his system at 300 BAUD. Some SYSOP's believe that 300 BAUD users have a "pre-puberty" mentality and cause more problems (i.e. infantile messages) for the SYSOP than their contributions justify. While RBBS-PC is intended to be as open a system as possible, each SYSOP has the option of electing to lock out 300 BAUD access. Another reason for denying access to 300 BAUD users is when RBBS-PC is running in a multi-tasking DOS environment that does not handle 300 BAUD very efficiently (i.e. like MultiLink). Whatever reasons a SYSOP has for denying access to 300 BAUD users, this option enables the SYSOP to select to do so using CONFIG rather than having to modify the RBBS-PC source code. 7.1.8 Are You Using ANSI.SYS With A Color Monitor ------------------------------------------------- Option 11 allows each SYSOP to see the color text files (i.e. menues, help files, etc.) exactly as the remote user sees them. Obviously the system running RBBS-PC should have a color monitor. More importantly each SYSOP that elects to activate this option should satisfy themselves that the program ANSI.ASM written and copyrighted by David Terry and modified by Dave Staehlin will not harm your particular brand Page 36 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 of color monitor or color graphics board. In order to effectively use this option you must have the ANSI.SYS driver loaded on your machine. This can be accomplished by including the statement DEVICE=ANSI.SYS within your system's CONFIG.SYS file. This load's the standard IBM- supplied ANSI.SYS file into your system. If you use an ANSI.SYS other than the one supplied by IBM, you may not see what your remote user sees. CAUTION: Dave Staehlin indicates the changes he made to the .ASM and .OBJ files reference some color page BIOS - hence, this may not work with a monochrome video card or within certain configurations! Similarly, it may not work with anything other than the standard IBM Color Graphics card and an IBM Color Monitor. Many "plug-compatable" color cards (like Hercules) have been known to burn out a monitor. Any SYSOP who elects this option takes on the SOLE responsibility and risk of determining if the combination of the many components envolved in the particular system RBBS-PC is to be run in (the ANSI.SYS, ANSI.OBJ/.ASM code, the color card being used, the color monitor, the BIOS, and the memory configuration) would cause damage to these or any of the other components within the system. To be safe, don't activate this option. If you do activate this option and your system is damaged, you should not expect to be reimbursed for such damage. This option is provided only as a convience to those SYSOP's who have assumed the sole responsibilities for any results that occur activating this option. Remember, this option need not be activated in order to run RBBS-PC normally! 7.1.9 Go Off-Line Whenever a Disk Full Occurs --------------------------------------------- Parameter 12 gives the SYSOP the option of electing to have RBBS-PC automatically take itself off-line if a "disk full" condition occurs. In previous versions, this was not an option. Now, if the SYSOP has a floppy disk for uploads that gets full and everything else is on a hard disk, the SYSOP can keep RBBS-PC from taking itself off-line should the floppy disk get full. 7.1.10 Prompt Sounds (can be changed by SYSOP from keyboard, too) ----------------------------------------------------------------- Parameter # 13 is the SYSOP'S preference for prompt sounds when input is required. This applies to remote and local. 7.1.11 Maximum Time on Per Session ---------------------------------- Parameter # 14 of the CONFIG program asks for the maximum amount of time each user is to be allowed on the system per session. Set the number of minutes to whatever you are comfortable with, but 72 minutes is a good setting for starting up. Subsequently you may have to lower this number once your number of callers increases, in order to keep callers' waiting times reasonable. This can also be made the maximum time on the system per day. As described in section 12.3, each security level can have its own maximum time on the Page 37 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 system per session specified. 7.1.12 Limit Maximum Time on System Per Day ------------------------------------------- You may limit the maximum amount of time any single user can spend on your system each day via parameter 15 of CONFIG. This is helpful if you have a relatively busy RBBS and want to have as diversified group of callers as possible. What this parameter does is to tell RBBS-PC to keep track of the total amount of elapsed time a user is on RBBS each day. Each time a caller logs on, the maximum amount of time that they are allowed on the system is checked against this daily cumulative total. The time remaining in each caller's session is the difference. When a caller exceeds this maximum and tries to log on again, they are told that they ahve exceeded the allocated time for that day and to try again tomorrow. 7.1.13 Months of Inactivity Before a User is Deleted ---------------------------------------------------- Parameter # 16 sets the number of months inactivity that must elapse before a user is deleted from the USERS file when the SYSOP "rebuilds" the user file (see section 7.8.2). 7.1.14 Communication Port to be Used ------------------------------------ Parameter # 17 requests the user to specify the communication port that RBBS-PC will be using in order to determine if it is device COM1 or device COM2. 7.1.15 Version of DOS RBBS-PC Will Run Under -------------------------------------------- Parameter 18 allows the SYSOP to specify the version of DOS that RBBS-PC will be running under. When RBBS-PC is running this is the ONLY indicator used by RBBS-PC when it has to determine what level of DOS it is running under. The correctness of this parameter is very significant when RBBS-PC options are invoked using commands specific to DOS 2.0 and above (i.e. the CTTY command for SYSOP function 7). 7.1.16 Name of RBBS-PC ---------------------- Parameter # 19 allows the SYSOP to specify the name of the RBBS-PC that is to be displayed when a user first connects with the system and prior to completing the logon process. 7.2 Global RBBS-PC Parameters (Part 2 of 2) ------------------------------------------- 7.2.1 Color Monitor's Foreground/Background/Border -------------------------------------------------- Parameters 21 through 23 allow the SYSOP to specify the colors desired for the foreground, background, and border. When specifying these options the BASIC manual's section describing the COLOR command in text mode should be consulted. This is useful when running multiple RBBS-PC's and you want a handy way of determine which RBBS-PC it is that you are viewing on the screen. This option is NOT available if the SYSOP has specified a "ring-back" system. PC.DEF file for a dedicated line.) Page 38 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 7.2.2 Selecting the Modem Speaker On or Off ------------------------------------------- There are times when the SYSOP no longer wants the speaker to be activated when a user logs on. The noise can drive anyone nutty on a busy RBBS-PC bulletin board (especially late at night). Option 24 allows the SYSOP to keep the modem speaker turned off at all times. 7.2.3 Reminding Users of Messages They Left ------------------------------------------- Option 25 allows the SYSOP to remind users not only of the messages that might be for them but also messages that they may have left. This should be enough of a nuisance to insure that users do delete some of the messages they have left and help to keep the MESSAGES file to a minimum. 7.2.4 Remind Users of Uploads and Downloads ------------------------------------------- Parameter 26 allows the SYSOP to elect to remind users of how many files they have downloaded and uploaded. 7.2.5 Remind Users of Their Profile Preferences ----------------------------------------------- Parameter 27 allows a SYSOP to remind users every time they log on of the preferences they have selected for such things as file transfer protocol, graphics, nulls, etc. 7.2.6 Default User Page Length ------------------------------ Parameter 28 allows the SYSOP to establish a default page length for users when they log on. A 23 line page length is the default, but the SYSOP can set it to any number between 0 and 255. If set to 0, the user will receive continuously scrolling output. 7.2.7 Maximum Number of Lines Per Message ----------------------------------------- Parameter 29 allows the SYSOP to specify (within the range of 1 to 30) the maximum number of lines allowed in each message. 7.2.8 Requiring non-ASCII Protocol for Binary Files --------------------------------------------------- Option 30 allows the SYSOP to tell RBBS-PC that files ending in binary file extensions (i.e. .ARC, .EXE, .COM, .OBJ, .WKS, .BAS, or whose second letter of the extension is Q) can not be downloaded unless the user selects XMODEM or MNP. This should eliminate some user problems before they occur. IBM's BASIC interpreter's SAVE command default is to write files in a special binary format (also referred to as 'tokenized') because they require much less disk space. 7.2.9 MICROCOM's MNP Protocol ----------------------------- Option 31 allows MNP to be optional within RBBS-PC. REGRETABLY, this option should not be selected with version CPC13-1A. This is because it was not possible to resolve the linkage incompatabilities between the new compilers and the MNP library and RBBS interface prior to the release of CPC13-1A. Every effort is being made to correct this particular problem. Page 39 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 Some SYSOP's may not wish to provide their users with the choice of MNP protocol (especially if they are employed by a company that has a competing protocol). RBBS-PC's features and growth are designed to be "additive." This parameter allows each SYSOP to decide if MNP protocol is to be available for file transfers. Microcom's error-free protocol, MNP, is available for file transfer beginning with version CPC12-4A of RBBS-PC. The RBBS-PC.EXE file includes code from the MNP library. The MNP library file provided with RBBS-PC is done so under the following condition: The MNP library file provided with RBBS-PC is the exclusive proprietary property of Microcom, Inc. and this copyrighted program material is supplied by Microcom exclusively for use with the RBBS-PC bulletin board system. Inclusion of library code within RBBS-PC does not in any way grant a license to the Microcom Networking Protocol (MNP). The use of the RBBS- PC MNP library code modules or MNP in any product other than the RBBS-PC program is a violation of Microcom's proprietary rights in the MNP technology. 7.2.10 Omitting First Level Directory in "New" Command ----------------------------------------------------- Option 32 allows the SYSOP to exclude the primary directory (DIR.DIR) from the search done by the New command. If you have multiple directories (i.e. RBBS.DIR through BASIC.DIR), any dates in the primary directory would not be of files. The "New" command (as in "What new files have been put on the download directories since I was last on?") search each line of each file whose extension is DIR for a date field. Since the first level directory is normally a listing of the other directories and their general subject areas, it is advisable to omit the first level directory from the "New" command. 7.2.11 Omitting Upload Directory in "New" Command ------------------------------------------------ Option 33 allows the SYSOP to exclude the directory on which users place the information on their uploads (i.e. 99.DIR) from the "New" command. As some SYSOP's wish to preview or otherwise keep private the uploads before putting them on the download directories, this acts as a further insurance against unauthorized access of a "private" upload directory. 7.2.12 Making System Welcome Interruptable ------------------------------------------ Option 34 allows the SYSOP to make the system "welcome" file interruptible. The default is that YES it is interruptible. However, if the SYSOP feels too many people are bypassing it and it contains essential information, the SYSOP can set this parameter to NO (i.e. the user can not suspend or cancel the listing of this file at their terminal with a CTRL S or CTRL K). 7.2.13 Making System Bulletins "Optional" ----------------------------------------- Parameter 35 is intended to allow the SYSOP to indicate if the system bulletins are to be an option for users when they log on. Page 40 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 7.2.14 Type of PC RBBS-PC Is Running On --------------------------------------- Option 36 is designed to allow RBBS-PC to run on some "IBM-compatible" PC's that make use of unused interrupts or on the IBM PCjr. RBBS-PC checks to see if the unused interrupt X'7F' is non-zero. If it is, RBBS-PC thinks that the software product, MultiLink (from The Software Link, Inc.) is present and issues the appropriate MultiLink calls. Obviously if this is not the case, strange and unpredictable things happen which result in RBBS-PC not working. The COMPAQ+ is an example of this syndrome. If running RBBS-PC on an IBM PCjr using an external modem but without an internal modem, the communications port must be opened as COM1 even though RBBS-PC must use the COM2 RS232 registers for controlling the communications port. 7.2.15 Issuing Modem Commands Between Rings ------------------------------------------- Option 37 allows the SYSOP to tell RBBS-PC either to wait to issue commands inbetween rings or to issue modem commands without waiting. Some modems cannot both handle the telephone ringing and accept modem commands simultaneously. Other modems, like the Hayes, can handle such simultaneous demands. For these later (i.e. Hayes, Prometheous, Multi- Tech, etc.) this option should be set to "NO." 7.2.16 Baud Rate to Open Modem Initially At ------------------------------------------- Some 2400 baud modems (like the Hayes) MUST be opened initially at 2400 baud because when they automatically answer the phone they can only "bump down" when automatically detecting baud rate (i.e. from 2400 down to 1200 down to 300). Parameter 38 allows the SYSOP to select the baud rate at which RBBS-PC is to open the modem at initially. 7.2.17 Seconds To Wait Before Logging Off Idle Users ---------------------------------------------------- The SYSOP can select the number of seconds that RBBS-PC will allow a user to be "idle" (i.e. not sending or receiving data) via parameter 39. 7.2.18 Using "Dumb" Modems -------------------------- If the SYSOP has a non-Hayes modem (i.e. one that will not recognize Hayes commands and will not return Hayes responses) that will only "auto-answer" the phone, parameter 40 allows the SYSOP to so indicate to RBBS-PC. Typically this would be some communications network (i.e. TymnNet) or local area network that supplied a simple RS232 interface. Selecting this option causes RBBS-PC to 1. Issue no Hayes commands, 2. Depend on no Hayes-like responses, 3. Control the interface with the Data Terminal Ready (DTR), 4. Assume somebody has called whenever Carrier Detect (CD) is detected, and 5. Assume that whomever calls is at the baud rate selected in CONFIG parameter 38. Page 41 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 7.3 Parameters for RBBS-PC "text" Files --------------------------------------- 7.3.1 Drive Containing RBBS-PC "Bulletins" ------------------------------------------ Parameter 41 indicates the disk drive on which RBBS-PC is to search for bulletins when a user requests to see them. 7.3.2 Name of File Describing the "Bulletins" --------------------------------------------- This is the text file that is shown to a user if bulletins are not optional (see parameter 35) or if the user replies "L" when notified of how many bulletins exist (see parameter 43). This file should contain a list of the bulletins (i.e. 1-99) and a brief one-line description of the contents of each (i.e. "New Release of RBBS-PC"). 7.3.3 Number of System Bulletins -------------------------------- Parameter 43 allows a SYSOP to have from 0 to 99 "bulletins." If there are 0 bulletins a user is notified that there are no bulletins. Bulletins should be brief, informative, and timely. I personally think that there should be very few bulletins and that they should be changed often if users are to be enticed to look at them. 7.3.4 Prefix Used to Name Bulletin Files ---------------------------------------- Parameter 44 provides the SYSOP with the flexibility to make the prefix of the bulletins anything he wants (i.e. BULLET). To this is added the number (i.e. BULLET7 for bulletin number 7) and the disk drive designated in parameter 41 is searched for the bulletin number requested when some asks to see a bulletin. If the file is not found, the user is so informed. If a "graphics" equivalent is found and the user has signed on N/8/1 and requested graphics, the graphics version of the bulletin is displayed (i.e. BULLET7G). 7.3.5 Drive Containing On-Line Help Files ----------------------------------------- Parameter 45 indicates the disk drive on which RBBS-PC is to search for to find RBBS-PC's on-line "help" files whenever a user asks for help within a specific subsystem. 7.3.6 Prefix Used to Name "Help" Files -------------------------------------- There are nine on-line "help" files used by RBBS-PC as described in section 6.2 previously. The SYSOP may chose to have them named something other than HELP01 through HELP08. Parameter 46 allows the SYSOP to pick up to a seven-character prefix to which the numbers 1 through 9 will be appended. This file name is what RBBS-PC will look for on the drive specified in parameter 45 when a user asks for help on-line. As with "bulletins", if a "graphics" equivalent is found and the user has signed on N/8/1 and requested graphics, the graphics version of the help file is displayed (i.e. HELP7G). 7.3.7 Name of "NEWUSER" file ---------------------------- This is the text file that new users see when they first log on and before they "register" themselves in RBBS-PC's USERS file. A user sees Page 42 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 it once and only once during his first session. It can contain anything you want it to, but a brief explanation of your Board's purpose, "rules", etc. might be appropriate. Parameter 47 allows the SYSOP to give the file any name he wants. 7.3.8 Name of "WELCOME" file ---------------------------- This is the text file that each user sees EVERY time AFTER they log on. Keep it brief! RBBS-PC will look for a "graphics" equivalent if the user qualifies for graphic displays (i.e. it will display the file HELLOG in lieu of HELLO). Parameter 48 allows the SYSOP to tailor this file's name to his own tastes. The file named "PRELOG" will be displayed as soon as carrier is detected and BEFORE a user can log on. It is displayed immediately after the name of the RBBS-PC is shown (see option 19) and providing it 1. has the name PRELOG and, 2. is on the same disk drive as the WELCOME file. SYSOP's should use "PRELOG" to convey such information as (real names are required, 300 baud users will automatically be denied access, etc.). 7.3.9 Name of File Describing File Directories ---------------------------------------------- See Section 9.0 for a description of file directories -- they have no relation to DOS 2.x and above "sub-directories!" Most SYSOP's categorize the files that are available for downloading into general groups (games, utilities, etc.). Parameter 49 allows the SYSOP to name the file that describes these groupings anything he wants. 7.3.10 Name of SYSOP's Command Menu ----------------------------------- Parameter 50 allows the name of the text file containing the commands allowed those with SYSOP privileges to be any valid name. Since such files are constantly accessed, it is recommended that the "menus" be placed in a RAM disk in order to cut down on the wear and tear of your disk drives. 7.3.11 Name of Messages Subsystem Command Menu ---------------------------------------------- Parameter 51 allows the name of the text file containing the commands available to those in the "messages" subsystem to be any valid name. Since such files are constantly accessed, it is recommended that the "menus" be placed in a RAM disk in order to cut down on the wear and tear of your disk drives. 7.3.12 Name of File Subsystem Command Menu ------------------------------------------ Parameter 52 allows the name of the text file containing the commands available to those in the "files" subsystem to be any valid name. Since such files are constantly accessed, it is recommended that the "menus" be placed in a RAM disk in order to cut down on the wear and Page 43 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 tear of your disk drives. 7.3.13 Name of Utilities Subsystem Command Menu ----------------------------------------------- Parameter 53 allows the name of the text file containing the commands available to those in the "utilities" subsystem to be any valid name. Since such files are constantly accessed, it is recommended that the "menus" be placed in a RAM disk in order to cut down on the wear and tear of your disk drives. 7.3.14 Menu that Lists Available Conferences -------------------------------------------- Parameter 54 is the name of the text file listing the names of the conferences that are available. Conference names must be seven- characters or less. Additionally, the SYSOP must already have pre- formatted the messages and users files associated with the conferences (see section 15.0). 7.3.15 File Containing Invalid User Names ----------------------------------------- Parameter 55 is the name of the text file listing names that the SYSOP considers inappropriate. This file is used when a new user signs on. The new user's first and last name are each individually checked against the names in this file. The format of this file is as follows: <name>, An example of such a file would be: KILLER, MAN, THE, DOC, DOCTOR, DEATH All names should be UPPER CASE! If you create the file using IBM's standard DOS text editor, EDLIN, each line should end with a comma. If you create the file using COPY CON, each line should end with a carriage return (i.e. the "enter" key). The last line (when using COPY CON) should end with a Control Z, F6, and then carriage return. BASIC will treat either a comma or a carriage return as a field delimiter. You need a field delimiiter following each of the names. If the above file existed, any new user who logged and used the following names would be denied access: Byte Killer Kilo Man Doctor Death PC Doctor The Best Page 44 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 7.3.16 Factor to Extend Session Time For Uploads ------------------------------------------------ Parameter 56 allows a SYSOP to "reward" users who upload files by adding some multiple of the elapsed time it took for the file upload to the current session time. This should be used judiciously as some users may abuse this by repeatedly uploading COMMAND.COM or some other meaningless file. This extends only the user's current session and NOT the elapsed time the user may be limited to per day via parameter 15. 7.3.17 Default System Type for New Callers ------------------------------------------ Parameter 57 allows a SYSOP to set the default system type for new users to something other than IBM PC (i.e. KAYPRO, COLUMBIA, WANG, etc.). 7.3.18 Drive Available for Uploading ------------------------------------ Parameter 58 specifies the letter of the single drive available that this copy of RBBS-PC can upload files to. When a file is uploaded, the file specified by CONFIG parameter 11 will be automatically appended with the file name, file size, date of upload, and short description as specified by the user. 7.3.19 Name of Directory to Update for Uploads ---------------------------------------------- Parameter # 59 of the CONFIG program asks for the name of the directory into which the file name, file size, and file description of uploaded files can be recorded. The default name is 99.DIR and it must be a text file on the drive designated for uploading (see section 7.3.19). 7.3.20 Drives Available for Downloading -------------------------------------- Parameter 60 specifies the letters of the drives from which files can be downloaded. The order in which they are specified is the order in which the drives will be searched. If the order is BAC, then drive B will be searched first for the file, then drive A, and finally drive C. While there can be duplicate files on each of the drives, the first file found will be the one downloaded to the user. 7.4 Parameters for RBBS-PC "system" Files ----------------------------------------- 7.4.1 Name of "MESSAGES" file ----------------------------- Parameter 61 allows the SYSOP to specify the file name for the file used by RBBS-PC to hold the messages on the bulletin board. This file canNOT have an extension because RBBS-PC appends the extension ".BAK" to the file name when "packing" the messages file. 7.4.2 Name of the "CALLERS" file -------------------------------- RBBS-PC maintains a log of user activity on a "callers" file. It contains information on the date, time, communications parameters of who logged on; what they uploaded or downloaded; and any security violations or errors that were generated. Parameter 62 allows the SYSOP to specify the fully qualified name for the file that RBBS-PC Page 45 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 uses for this log. 7.4.3 Name of file containing "Comments" for the SYSOP ------------------------------------------------------ Instead of leaving a "message", a user may leave a comment for the SYSOP that is readable only by the SYSOP. Parameter 63 allows the SYSOP to specify the fully qualified name for the file used by RBBS-PC to store users' comments. 7.4.4 Name of the "USERS" file ------------------------------ RBBS-PC keeps a profile of each user who logs on in a "user record" (see Appendix A for a layout of this record). Parameter 64 allows the SYSOP to specify the file name for this file. This file canNOT have an extension because RBBS-PC appends the extension ".BAK" to the file name when "packing" the users file. 7.4.5 Extended Logging To "CALLERS" File ---------------------------------------- If parameter 65 is selected the following ten additional items of information are included in the CALLERS file: 1) "Connect not completed" 2) "Sleep disconnect" 3) "Caller changed name/address" 4) "Newuser" 5) "Bulletin# read" 6) "Sysop initiated Chat" 7) "Entered Conference name" 8) "Time limit exceeded" 9) "Left comment at time" 10) "Logged off at time" It should be remembered that for each occurrance of the above, the CALLERS file will increase by 64 bytes. Unless you either have a hard disk or are willing to frequently maintain your system in order to leave enough free space on the disk drives for new files, this option should NOT be activated. 7.5 Parameters for RBBS-PC "Doors" ---------------------------------- 7.5.1 Enabling the "Door" Subsystem ------------------------------------ Parameter 81 allows the SYSOP to enable RBBS-PC to exit and return to the system (i.e. DOS). The batch file out of which RBBS-PC is invoke should then check to see if a "door" is to be invoked. A "door" is simply a batch file that the SYSOP has created which RBBS-PC users are allowd to exit to and which will then take control of the remote user's communication port. REMEMBER -- if you are going to use "doors" the program EXITRBBS.EXE must be on the same drive or in the same DOS sub- directory as RBBS-PC.EXE. 7.5.2 Name of Menu that Lists the Available "Doors" --------------------------------------------------- Parameter 82 allows the SYSOP to specify the fully qualified file name of the menu that lists the names of the "doors" available to users. Page 46 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 RBBS-PC checks this file to verify that the name of the door that the user requested is in the doors menu (see Section 11). 7.5.3 File RBBS Builds Dynamically to Open a "Door" --------------------------------------------------- Parameter 83 allows the SYSOP to specify the fully qualified file name of the file that RBBS-PC is to use when dynamically building the .BAT file that invokes the "door" selected by the user. The batch file that invokes RBBS-PC must contain an "IF" to check if this file exist whenever RBBS-PC terminates and (if it exists) to execute it (see Section 10). This is also the same file name that is used when the SYSOP exits to DOS. 7.5.4 File to Re-invoke RBBS-PC when a "Door" Closes ---------------------------------------------------- When a door finishes RBBS-PC is re-invoked. Parameter 84 allows the SYSOP to specify the fully qualified file name of the .BAT file that should be used to re-invoke RBBS-PC (see sections 10 & 11). This is also the same file name that is used when the SYSOP returns from exiting to DOS. 7.5.5 Drive to Look For COMMAND.COM On -------------------------------------- Whenever you exit to a "door" or to DOS (via the remote SYSOP's function 7), RBBS-PC needs to know where to find COMMAND.COM. In a network environment with several PC's the COMMAND.COM's may be different for each PC. Parameter 85 allows the SYSOP to specify for the each copy of RBBS-PC a disk drive on which to find the COMMAND.COM appropriate for that copy of RBBS-PC. 7.6 Parameters for RBBS-PC's Security ------------------------------------- 7.6.1 Minimum Security Level to Get Into RBBS --------------------------------------------- Parameter 101 specifies the minimum security level users need in order to log onto RBBS. If the default is less than this value, no new users can logon on. This means that the board is closed to new users and access limited only to pre-registered users). Since RBBS-PC is intended to facilitate the free exchange of information, you are strongly urged not to use RBBS-PC in this way. Section 12.1 details other ways a SYSOP can control access to his RBBS-PC. 7.6.2 Default Security Level for New Callers -------------------------------------------- Parameter 102 specifies the security level that will be assigned to all new callers. At the very least, it is recommended that this value be equal to the security level assigned to the C>omments and G>oodbye commands via option 109. 7.6.3 Default Security Level for SYSOP -------------------------------------- Parameter 103 allows you to specify the minimum security level a user must have to be considered an "assistant" SYSOP by RBBS-PC. Even if a user has a high enough security level to see the SYSOP's menu and execute some or all of the SYSOP commands, the user will not be treated as a SYSOP (i.e. allowed to see the files upload/download when viewing Page 47 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 the CALLERS file) unless the user's security level is equal to or greater than that specified by parameter 103. 7.6.4 File of File Names with Download Security ----------------------------------------------- Parameter 104 specifies the name of the file that contains a list of file names that CANNOT BE DOWNLOADED (even if they are on the disks that are available for downloading) unless the user supplies a password and/or is at a specific security level. If you want to have no file security at all, just put no file names in this file. If you include a password with a file name all users (including one with SYSOP privileges) must be able to give the password in order to download the file. For a more detailed description of this file and how it works, see section 12.4 -- "How to Implement the Security for Download Files." 7.6.5 Minimum Security Level to See SYSOP's Menu ------------------------------------------------ Parameter 105 prevents the SYSOP menu from being displayed (even if the user has a security level of a SYSOP as specified in option 103) unless the user is also at this security level. 7.6.6 Minimum Security Level to Use RBBS-PC "Doors" --------------------------------------------------- Parameter 106 allows the SYSOP to set the minimum security level a user must have to exit RBBS-PC via a "door". This security level must be equal to or higher than the security level for the "D>oor" command (see Parameter 110). 7.6.7 Maximum # of Security Violations Before Lockout ----------------------------------------------------- Parameter 107 allows a maximum number of security violations (i.e. attempts to download protected files) before the user is logged off and locked out. 7.6.8 Security Levels for Each Command -------------------------------------- Parameters 108 through 111 allow the SYSOP to set up the security levels required to issue the commands in the SYSOP, Main Menu, File Subsystem, and Utilities Subsystem (respectively). All the commands in each area can be given the same security level or, optionally, a specific command can be given a unique security level. 7.6.9 File with Privileged Group Passwords ------------------------------------------ Parameter 112 specifies the file name which contains the privileged group passwords that allow users to change temporarily their security, time on the system, etc. -- if the SYSOP has set it up that way. Callers shift to a group password by changing passwords. If the password they select is found in the file containing the privileged passwords, their private logon password is unchanged and they receive the security level and/or time limit associated with the group password. If you have no group passwords, just put nothing in this file. For a more detailed description of this file and how it works, see section 12.3 -- "How to Implement the Password File." Page 48 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 7.6.10 Maximum # of Password Changes Per Session ------------------------------------------------ Parameter 113 allows the SYSOP to specify the maximum number of times users can change their passwords in a given session. 7.6.11 Minimum Security for Temporary Password Changes ------------------------------------------------------ Parameter 114 is the minimum security level required in order for users to change temporarily their security or time on the system via privileged group passwords. If users do not have the minimum security level to temporarily change their password, ALL password changes that they make will be permanent -- even if the password they select is in the temporary password file named in parameter 112 of CONFIG! 7.6.12 Minimum Security to Overwrite Files on Uploads ----------------------------------------------------- Parameter 115 allows the SYSOP to specify a security level that has the privilege of overwriting files (i.e. files that already exist) when uploading. 7.6.13 Security Level of Conference "Viewers" --------------------------------------------- Parameter 116 allows the SYSOP to specify a temporary security level that will be in effect when a user wishes to "view" a conference. In this way a user might be able to S>can (i.e. see the date, time, subject, etc.) of the messages in a conference without having to be pre-registered in the conference. Not currently implemented (as of CPC13-1A). 7.6.14 Security Level Exempt from Purge of USERS File ----------------------------------------------------- When the SYSOP "purges" the USERS file, all users who have not signed on within the number of months specified in parameter 16 are deleted from the file with the exception of those who have been "locked out" and those whose security level is equal to or greater than that specified in parameter 117. 7.7 Parameters for Multiple RBBS-PC's ------------------------------------- 7.7.1 Maximum Number of Concurrent RBBS-PC's -------------------------------------------- RBBS-PC CPC13-1A allows multiple RBBS-PC's to run in the same environment/network and share many of the same files. If you ever plan to do this or if you are going to do this, set this number to the MAXIMUM number you ever envision running. Up to 36 RBBS-PC's can share the same files. Depending on the environment, 4 to 5 copies of RBBS- PC's may turn out to be the operationally effective maximum. Parameter 121 allows you to specify the maximum number of RBBS-PC's that the MESSAGES file should be initialized for. 7.7.2 Environment Running Concurrent RBBS-PC's ---------------------------------------------- Parameter 122 allows the SYSOP to designate the type of environment that multiple copies of RBBS-PC will be sharing files in. This is necessary so that RBBS can use the mechanism that is appropriate to the Page 49 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 specific environment when sharing files. RBBS-PC CPC13-1A currently can handle the following environments for multiple RBBS-PC's: 1. MultiLink (The Software Link, Inc.) 2. OmniNet (Corvus) 3. PC-Net (Orchid) NOTE: Many manufacturers utilize Orchid's network conventions. As an example, AST and Alloy are both vendor's whose "network" is .EXE file- compatable with Orchid's (i.e. "An Orchid by any other name is still an ..."). If you have a network of PC's, check with the vendor to see how compatable their network is with those supported by RBBS-PC. 7.7.3 Method RBBS-PC Uses to "Recycle" When Users Logoff -------------------------------------------------------- Some local area network environments are not designed to have applications constantly branch back to the beginning and re-open already open files. If you are in this environment or simply want to run external programs after a user logs off or RBBS-PC recycles, parameter 123 allows you to elect to do this. If you specify "internal", RBBS-PC will function as it currently does and branch back to its beginning. If you specify "system", RBBS-PC will exit to DOS and (if you are running RBBS-PC out of a .BAT file) you can then automatically invoke any other "housekeeping" programs you want before re-invoking RBBS-PC. It should be noted that this will add a considerably delay to RBBS-PC's recycling time as RBBS-PC will have to reloaded back into memory every time it recycles. 7.7.4 Maximum Number of Records in the "USERS" File --------------------------------------------------- Like the MESSAGES file, the USERS file must also be static in length for RBBS-PC CPC13-1A. Parameter 124 allows the SYSOP to set the size of the USERS file. RBBS-PC automatically keeps track of the records available for use in this file and does the necessary "housekeeping." When the USERS file get full (i.e. all its records are used up) and the SYSOP neither "packs" it nor increases the size of the file, no new users will be able to log on until one of these two events occurs. 7.7.5 Maximum Number of Records in the "MESSAGES" File ------------------------------------------------------ RBBS-PC CPC13-1A requires that the "Messages" file be static in length. It automatically keeps track of the next record available and does the necessary housekeeping to maintain the integrity of the file. Parameter 125 allows the SYSOP to set the size of this file. CONFIG.BAS will automatically determine what size the current file is and will reformat a pre-CPC12-3A MESSAGES file if it finds one. If you do not increase the size of your existing MESSAGES file, no one will be able to leave any new messages. Similarly, when the MESSAGES file get full (i.e. all its records are used up) and the SYSOP neither "packs" it nor increases the size of the file, no one will be able to leave a message until one of these two events occurs. Page 50 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 The minimum size of the MESSAGES file is equal to 1 (The "checkpoint" record) + the maximum number of concurrent RBBS-PC's ("node" records) + the maximum number of messages allowed X 5 (each messages is assumed to average five 128-byte records) Therefore, if option 121 of CONFIG where 12 and option 126 of CONFIG where 50, the minimum number of records that could be specified for option 125 would be 1 (The "checkpoint record) + 12 (The number of "node" records) +250 (50 messages x 5 128-byte records each) ---- 263 records for the MESSAGES file 7.7.6 Maximum Number of Messages Allowed ----------------------------------------- Parameter # 126 lets you set the maximum number of messages that the SYSOP will allow on the system at any one time. The number will have to be based on the size of the average message on your bulletin board. Most messages require about 600 bytes on the average. The absolute upper limit on the number of messages is 250. If you specify 250 messages, you can expect that the MESSAGES file will be preformatted to more than 160K in size. 7.7.7 Conference File Maintenance --------------------------------- Parameter # 127 allows "conference" files to be maintained. A "conference" consists of a message file and, if a "private" conference, a corresponding users file. The name of the conference can be anything that the SYSOP selects but can not be longer than 7 characters. The message file's name for a conference consists of the conference name plus the characters "M.DEF". The user file's name assocated with "private" conferences consists of the conference name plus the characters "U.DEF". Parameter # 127 allows the SYSOP to create, expand, or contract either or both of the files associated with a "conference." This occurs ONLY when the SYSOP "ENDs" the CONFIG session by pressing the key marked END. Parameter # 127 allows the SYSOP to perform all the functions on page 8 of CONFIG on the conference that was named/selected with Parameter # 127. For a further discussion of "conferences" see section 15.0. 7.8 RBBS-PC SYSOP Utilities --------------------------- 7.8.1 Packing the "MESSAGES" file --------------------------------- The message file contains all messages for the RBBS-PC system. As messages are killed they are only flagged as inactive. Parameter 141 should be used periodically to recover the space occupied by the killed messages. After completion, only the text of active messages will be present and the old file will remain on the system with the name of MESSAGES.OLD. Also, you will need enough free disk space for the MESSAGES and MESSAGES.BAK files when packing the MESSAGES file or the packing cannot be performed. If enough space is not found the Page 51 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 packing will terminate abnormally and the MESSAGES file will be recovered. 7.8.2 Rebuilding the "USERS" File --------------------------------- Parameter 142 removes deleted users and users who have not been on the system within the number of months specified using parameter 16 in CONFIG. You should have enough free disk space for USERS and USERS.BAK or the rebuilding will terminate abnormally (the USERS file will be restored). It is important to note that beginning with CPC12- 5A, the USERS file is no longer a random file that is accessed sequentially but now is a random file that is accessed directly. When a user logs on RBBS-PC "hashes" the users name to find the user's record directly in the USERS file. That is why the USERS file's size is a power of 2 (i.e. 256, 1024, etc.). This allows users to log on much more quickly to RBBS-PC's that have a very large number of users. 7.8.3 Printing Message Header Records ------------------------------------- Parameter 143 will display the message headers of all messages, active and killed, that are present in the message file. This is left over from one of the many "debugging" stages of RBBS-PC prior to CPC09. Following the policy of making all changes "additive", this function has been retained. It may help some SYSOP's recover from disk hardware failures. 7.8.4 Renumbering Messages -------------------------- Parameter 144 permits messages to be renumbered sequentially starting from a specified message using whatever starting number you wish. Please note that there is not much error checking to be sure that the new numbers do not duplicate those of lower numbered active messages. When complete, the next message to be created will be the next higher number from the resequence. Unpredictable results will occur if a SYSOP creates messages with duplicate numbers! 7.8.5 Repairing the MESSAGES file --------------------------------- Parameter 145 goes through the MESSAGES file and reconstructs the chains that link the messages together. MESSAGES files that have "blank" messages or abbreviated messages (i.e. some lines of text are missing) can be repaired with this facility. 7.8.6 Initialize Hayes 2400 Firmware for RBBS-PC ------------------------------------------------ Parameter 146 allows the SYSOP to set the Hayes 2400 firmware to match RBBS-PC's requirements as described in section 8.1. Additionally, the SYSOP may prevent callers from using the the Hayes 2400 connected to the RBBS-PC system for remote digital loop back testing. This is the recommended setting for parameter 146. Page 52 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 7.9 Use of DOS Subdirectories ----------------------------- 7.9.1 Using DOS Subdirectories ------------------------------- Parameter 161 allows the SYSOP to indicate that DOS subdirectories are to be used by RBBS-PC. The support of DOS subdirectories began with RBBS-PC version CPC13-1A. If this option is selected, CONFIG will also display option 164. 7.9.2 Upload DOS Subdirectory ------------------------------ Parameter 162 allows the SYSOP to indicate the DOS subdirectory to which uploads are to be written. RBBS-PC will prepend the upload disk drive to it (see parameter 58 described in Section 7.3.18) and append the upload file name after it when uploads are written to disk. If an upload DOS subdirectory is selected the upload directory (see parameter 59 described in Section 7.3.19) must be on the upload disk within that DOS subdirectory. Just as there can only be one disk drive and one upload directory specified, there can only be one DOS subdirectory specified for uploads. 7.9.3 Download DOS Subdirectories --------------------------------- Parameter 163 allows the SYSOP to indicate that DOS subdirectories are to be used when searching for files on downloading. A valid download drive followed by a colon, a reverse backslash, and the subdirectory name that is to be searched must be entered. If the root directory is also to be searched, just enter a valid download drive followed by a colon. The search is similar to that described for parameter 60 (see Section 7.3.20). Each download disk drive is searched for only those subdirectories that were specfied as existing on that specific drive. If two download DOS subdirectories are specified (A:\TEST1 and B:\TEST2) and two download disk drives for parameter 60 (A and B), the search for a download file will be in the following order: A:\TEST1\filename B:\TEST2\filename It is possible to have the same subdirectory name on different download drives. Each would have to be individually specified (A:\GAMES and B:\GAMES If they where, the search for a download file would be as follows: A:\GAMES\filename B:\GAMES\filename 7.9.4 List, Change, Add, Delete DOS Subdirectories Used ------------------------------------------------------- Parameter 164 only appears if option 161 has been specified as "YES." This parameter allows the SYSOP to list, change, add, or delete the DOS subdirectories to be used for either uploading (parameter 162) or downloading (parameter 163). CONFIG does NOT acutally create or delete such DOS subdirectories -- that's up to the SYSOP to do using the standard DOS commands. Parameter 164 simply allows the SYSOP which DOS subdirectories will (or may) exist when RBBS-PC is running. Page 53 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 8.0 HAYES COMMANDS AND MODEM SWITCH SETTING CONSIDERATIONS ---------------------------------------------------------- 8.1 Hayes Modem Switch Setting Considerations --------------------------------------------- RBBS-PC is tested with a HAYES Smartmodem 1200 (i.e. external). The switch settings on the modem must be as follows: switch -- 12345678 setting - UUDDDUUD Recognizing that there are many "Hayes-compatible" (and not so compatible) modems in use, this section is intended to assist those adventurous souls who use such modems and need some guidance on what the otherwise mystical Hayes switch settings mean. The following table may be of some help: Setting Function to RBBS-PC Hayes ----------------- Switch Factory RBBS-PC ------- ------- 1 Down Up Allows RBBS-PC to control the modem using the RS-232C DTR lead (pin 20). 2 Up Up Not meaningful to RBBS-PC (could be down) and is used to indicate if result codes are to be English words or single digits. RBBS-PC sets this with the Hayes "V" command. 3 Down Down Not meaningful to RBBS-PC (could be down) and is used to indicate if result codes are to be sent to RBBS-PC. RBBS-PC sets this with the Hayes "Q" command. 4 Up Down The modem does not echo characters unless half-duplex is selected and the modem is on- line. 5 Down Down Modem is NOT to answer incoming calls. RBBS- PC monitors the ring indicator (pin 22) to determine if the phone is ringing. If it is, RBBS-PC will issue the necessary commands to the modem. 6 Down Up RBBS-PC checks for the carrier signal using the RS-232C Carrier Detect lead (pin 8). If carrier is lost, RBBS-PC hangs up the phone and re-cycles to await the next call. 7 Up Up Not really required by RBBS-PC. However in the "down" position, the telephone extension light will illuminate on a multi-line installation when the modem answers a call. 8 Down Down Enables the Smartmodem 1200 to recognize the Hayes commands issued by RBBS-PC. Page 54 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 The most common problem, "RBBS-PC continually recycles," occurs when switch six is left in the factory position. These switch settings do not have to be changed for most other communications software packages. (You can leave the switches set as shown above if you use PC-TALK for your smart terminal communications. However, you will be advised to give the modem an "ATZ" command before using PC-TALK in order to reset the registers correctly.) RBBS-PC should be used only with versions 123 and above of the Hayes Smartmodem 1200 and with version 247 and above of the Hayes Smartmodem 2400. Earlier versions do not answer the telephone properly. The ATI command will cause the Smartmodem to tell you its version. Hayes is now shipping an external modem called the Hayes 1200FE that has 10 switch settings. To run RBBS-PC switches 9 and 10 of the 1200FE must be left up (the factory setting). Hayes is also now shipping an internal modem called the Hayes 1200BFE that has 6 switch settings. To run RBBS-PC switches 4, 5, and 6 must be left up (the factory setting). If you can't figure out what the switching settings on these new modems should be based on the switch settings given for the "original" Hayes 1200, CALL HAYES TECHNICAL SUPPORT! Since I don't have the newer modems, I won't be of much help if you call me. 8.2 Hayes Command's Considerations ---------------------------------- The Hayes commands used to control the modem are all external to RBBS-PC beginning with version CPC13-1A. These command strings are in the RBBS- PC.DEF file which may be modified by any file editor that can handle ASCII files (i.e. DOS' EDLIN utility). The RBBS-PC.DEF file contains five Hayes command strings -- one on the second line of the .DEF file and four on the last line of the .DEF file. Using RBBS-PC's CONFIG utility's defaults, the command strings are as follows. The first command string, on the second line of the .DEF file is: Command Meaning AT Signifies the following characters are Hayes commands. M0 Turn the monitor speaker on the modem off permanently. Q1 Do not return result codes to the PC. S2=255 Disable escape code detection. S10=30 Do not drop disconnect user unless carrier drops for more than seconds. E0 Do not echo characters back to the PC when receiving Hayes commands. S0=0 Disable the modem from automatically answering the phone (let RBBS-PC control when the phone is answered). This command is the second command issued to the modem every time RBBS-PC gets ready for calls. Page 55 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 The second command string in the .DEF file is the first Hayes command string on the last line of the .DEF file and is: Command Meaning AT Signifies the following characters are Hayes commands. Z Causes a software reset and applies all default values. This is the first command issued to the modem every time RBBS-PC gets ready for calls. The third command string in the .DEF file is the second Hayes command string on the last line of the .DEF file and is: Command Meaning AT Signifies the following characters are Hayes commands. S1? Requests the modem to return the number of times that the phone has rung. This command string is only issued when CONFIG has been used to tell RBBS- PC to answer on a specific number of rings. In the default settings for CONFIG, this command is never used. The fourth command string in the .DEF file is the third Hayes command string on the last line of the .DEF file and is: Command Meaning AT Signifies the following characters are Hayes commands. Q0 Tells the modem to send result codes to the PC. X1 Tells the modem to send "extended" result codes to the PC. V1 "Extended" result codes are to be transmitted as words. A Tells the modem to answer the phone immediately. This command is ALWAYS issued if the default settins of CONFIG are selected. RBBS-PC utilizes the extended verbal results code (CONNECT, CONNECT 300, CONNECT 1200, and CONNECT 2400) to determine the callers baud rate. Some Hayes 300 modems doen't function with RBBS-PC because they do not recognize the "X1" command. If you have a modem like this, simply remove the X1 command from the command string in the .DEF file. The fifth command string in the .DEF file is the fourth Hayes command string on the last line of the .DEF file and is: Command Meaning AT Signifies the following characters are Hayes commands. Q1 Do not return result codes to the PC. E1 Echo characters back to the PC when handling Hayes commands. H1 Take the modem off the hook (i.e. busy out the line). M0 Turn the monitor speaker on the modem off permanently. This command is issued whenever the SYSOP is doing local maintenance (i.e. hits ESC). Page 56 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 9.0 USING MULTIPLE FILE DIRECTORIES ------------------------------------- With the advent of CPC12.0, multiple file directories for downloads were possible. A file directory IS NOT A DOS "SUBDIRECTORY!" It is simply a text file that the SYSOP has created which has a one-line entry for each file available for downloading in the format: file name extension xxxx mm-dd-yy description that associates a size, date and description for each file name/extension. There are a few conventions regarding download directories. They are as follows: o The file directories must be text files. o The file directories must have an extension of up to three characters. The default extension is ".DIR". The 8-character file name and extension can be anything you want as long as it is a valid DOS file name. o There is only one file directory for uploads and it must be on the disk drive designated for uploads. o Filename should start in column 1. o Extension should start in column 10. o Program size can be between columns 14 & 22. o Date available for downloading must start in column 24 and should use MM-DD-YY or MM/DD/YY format. o Description should start in column 34. Most SYSOP's tend to organize their file directories according to subject. The primary file directory usually tells how you list the other directories. Logically, it looks like a tree structure as follows: DIR.DIR | | -------------------------------------------------------------- | | | | | | | | | aa.DIR bb.DIR ............................................ zz.DIR The suffixes aa through zz can be anything you want. Most RBBS-PC SYSOP's use numbers (i.e. 1.DIR, 2.DIR, etc.). The command L;2 would list 2.DIR. The SYSOP has the option of letting users know the name of the file directory for uploads. Some SYSOPS do and some don't. You may exclude both the directory of directories and the upload directory from the list new function (N) within the file subsystem (see sections 7.2.10 and 7.2.11). Page 57 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 10.0 SETTING UP ".BAT" FILES FOR RBBS-PC ----------------------------------------- Many SYSOPS have set up batch files to invoke RBBS-PC automatically and to re-invoke RBBS-PC should there be a power outage. These files range from the simple to the sublime in terms of complexity. In a multiple RBBS-PC environment, these .BAT files CANNOT BE SHARED. If you are going to exit RBBS-PC and transfer control to DOS remotely (either via the SYSOP's function 7 or via "doors"), it is necessary that: 1. RBBS-PC be executed from a batch file. 2. The batch file which is executing RBBS-PC contain an "IF" statement that checks for the existence of the batch file which RBBS-PC dynamically builds when either "doors" or SYSOP function 7 is invoked. 3. Within the "IF" statement, the logic exists such that the batch file dynamically built by RBBS-PC for the "doors" functions or SYSOP function 7 will be invoked if it exists. As a very simple example, let us assume that: 1. the batch file that invokes RBBS-PC is named A:RBBS.BAT, and that is what was entered for option 84 of CONFIG.BAS, 2. the name of the batch file that RBBS-PC will build dynamically for either "doors" or SYSOP function 7 is A:RCTTY.BAT, and that is what was entered for option 83 and 3. the compiled version of RBBS-PC is being executed and is named RBBS-PC.EXE and is on the default disk drive. 4. you have elected to use the watchdog utility program. 5. COM1 was designated as the communication port to be used by RBBS-PC. Then A:RBBS.BAT (in a non-MultiLink environment) would contain the following: WATCHDG1 OFF IF EXIST A:RCTTY.BAT DEL A:RCTTY.BAT RBBS-PC x (see note of values available for "x") IF EXIST A:RCTTY.BAT WATCHDG1 ON IF EXIST A:RCTTY.BAT A:RCTTY.BAT A:RBBS.BAT NOTE: When running RBBS-PC.EXE, RBBS-PC will check for the "x" in the command line that invoked RBBS-PC. The "x" on the execute line is extremely important to the correct operation of RBBS-PC. If you are running in a local area network environment then the "x" should be a number between "1" and "0" or a letter between "A" and "Z". If "x" is omitted from the command line, RBBS-PC will look for a file named RBBS- PC.DEF. RBBS-PC uses the parameter in the command line to determine the correct RBBSxPC.DEF file to use for its configuration parameters. Obviously the RBBS.BAT file could be as complex as you wanted it to be, but at the very least it would need the "IF" statements. Page 58 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 11.0 THE USE OF RBBS-PC "DOORS" ------------------------------- The RBBS-PC "door" concept is that of allowing a SYSOP to set up a "door" through which users can exit from RBBS-PC and enter other applications. In previous versions of RBBS-PC (i.e. prior to CPC12-3A) this had been called "windows" but because of the confusion this created with the WINDOWing concepts of other software, it has been re-labeled "doors". RBBS-PC's "doors" are nothing more than .BAT files that the SYSOP has created to allow users to exit from RBBS-PC and enter other applications (i.e. databases, etc.). The SYSOP is responsible for writing the .BAT files that users will be allowed to invoke. Assuming that RBBS- PC is brought up by DOS via an autoexec file that invokes RBBS.BAT, a door called EDIT exists that consists of a .BAT file (EDIT.BAT) which contains the commands CTTY, EDLIN, and RBBS.BAT. In order to exit RBBS-PC (either for a "door" or for the remote SYSOP's function 7) without the code that the BASIC compiler generates for you dropping the remote user, it is necessary to "RUN" to a dummy program called EXITRBBS.EXE. Here is pictorially what happens: DOS | \|/ AUTOEXEC.BAT | \|/ RBBS.BAT | +--------->RBBS-PC.EXE | \|/ "RUN" | / EXITRBBS.EXE +--------------+ | \ RBBS.BAT | \|/ RCTTY.BAT<-----invokes door called "EDIT" | \|/ EDIT.BAT | +--------->EDLIN.COM | | RBBS.BAT<--------ends | +--------->RBBS-PC.EXE | | welcome back from door and RBBS-PC continues Page 59 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 To set up "doors" the SYSOP lists the names of these .BAT files (which the SYSOP is responsible for setting up) in MENU5. If the SYSOP has indicated that doors are available (via CONFIG.BAS' option 81), when a user invokes the D>oor command, RBBS-PC will: 1. List MENU5, 2. Check that the door that the user selects was specified in MENU5, 3. Check that the .BAT file exists (on the default drive), 4. Dynamically create a .BAT file with the name specified by the SYSOP in option 83 of CONFIG.BAS that: a. invokes the .BAT file of the window specified,and b. re-invokes RBBS-PC after the user EXITS from the "door" by invoking the .BAT file that the SYSOP specified in option 84 of CONFIG.BAS. The purpose of "doors" is to allow for the "horizontal" growth of RBBS- PC. Clearly RBBS-PC has about all that IBM's BASIC compiler can handle. In order to not limit the application of RBBS-PC either to BASIC or the current compiler, "doors" was chosen as a mechanism to allow SYSOP's to make available other features (i.e. databases, games, etc.). Hopefully with RBBS-PC as a base, the limitations on doors will only be the SYSOP's resourcefulness AND IBM'S DISK OPERATING SYSTEM (see section 14)! The design of the .BAT file that is to be used as a "door" is critical and is the responsibility of the SYSOP. At the very minimum it should handle the communication port I/O. This can be done in a very primitive way using the DOS CTTY command and and a utility similar to WATCHDOG (written by Jim Reinders) that is described in section 14.1. Finally, if the preceding discussion of "doors" is a complete mystery to you, contact a SYSOP of an RBBS-PC that is using "doors" and ask for help. The "door" concept stretches IBM's DOS' capabilities and requires an extraordinary knowledge of how both DOS and .BAT files work. Page 60 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 12.0 THE SECURITY FEATURES OF RBBS-PC -------------------------------------- RBBS has always been an open system designed for public use. A SYSOP should always ASSUME that EVERY FILE ON THE PC running RBBS-PC CAN BE DOWNLOADED AND/OR DESTROYED. However, RBBS-PC has extensive safeguards that systematically enhance security and privacy. For example, RBBS-PC has the logic within it's code to prohibit anyone (including SYSOP's) from downloading the RBBS-PC "system" files described in section 6.1. RBBS can still be run as a wide-open system, but the SYSOP has many additional options to restrain access. These security options make RBBS much more suitable for private and business use. RBBS-PC's security is controlled by three things: 1. the system configuration file (RBBS-PC.DEF), 2. the two external security files for a. passwords (PASSWRDS), and b. file downloads (FILESEC), and 3. the users file (USERS) in which each user has an assigned security level. The users file is controlled by the SYSOP's user maintenance function 5 as described in section 13.1. To change a specific user's security level you select the M>odify option and then the S>ecurity option. This allows you to set the security level for a user. Users cannot set their own security levels. Section 12.3 describes how to implement special passwords that provide special privileges to the groups that issue them. Section 12.4 describes how specific files, groups of files, or even whole disk volumes can have download security levels associated with them. 12.1 RBBS-PC's Security Features -------------------------------- Each user has an assigned security level. This is an integer in the range -32,000 to +32,000. There are then over 65,000 possible security levels. Each command in RBBS also has a security level assigned to it. Security assignments are controlled by the SYSOP. To use a command, the caller's security level must be at least as high as the command's security level. The SYSOP can assign a file or group of files both a security level and a password. To download a file, a caller must have a security level at least as high as the file's and be able to give the file's password (if one is present). All users must pass these security tests, including anyone with SYSOP privileges. Messages can now be assigned a password by their creator. Then only persons who are able to give that password can read or kill the message. Messages with password protection will show <PROTECTED> when scanned. Callers have no way of distinguishing messages to private individuals and to groups except by how they are addressed. Persons with SYSOP privileges can read all messages. Section 12.2's description of sending a message to an AUTHORS SIG as an addressee with the password of AUTHORONLY shows how to send a message to a special group. Security violations are logged to the CALLERS file. These include attempting to use functions without sufficient security clearance, and Page 61 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 failure to give required passwords. RBBS-PC's default configuration is that of an "open" system. RBBS-PC's security system provides the SYSOP with several choices on how to run RBBS-PC. The chief ones are as follows: 1. Change the bulletin board from an open system available to all callers, to a pre-registered system available only to specified users. To support this option, there is a function in the SYSOP's user maintenance option 5 to ADD users. 2. A SYSOP can set up different "classes" of users by assigning different security levels to different users. Concurrently the SYSOP would have to assign different security levels to different commands. For example new callers might be permitted only to leave a comment, read bulletins, and list files that can be downloaded. Or there might be a group of files assigned a security level that only members of a special interest group can download. 3. The SYSOP can segregate the functions of the bulletin board into different groups based on a password. A specific file or group of files can be downloadable only to those who knew the password. Similarly, messages can be made open to everyone knowing the password but closed to everyone else. This way there can be semi-private portions of the bulletin board. 12.2 Examples of Uses for RBBS-PC's Security System --------------------------------------------------- Some examples of how a SYSOP can tailor RBBS-PC using RBBS-PC's extensive security features follow. SPECIAL INTEREST GROUPS -- A special interest group (SIG) in a users group wishes to run a RBBS for both the general public and its own use. An example would be an authors SIG for persons interested in publishing books and articles or developing commercial software. A definite need would exist to be able to address messages to everyone in the SIG without making them open to every caller. The SIG would establish the convention to password protect general SIG messages with the password AUTHORONLY, and to address them to AUTHORS SIG. Another example would be a bulletin board devoted to the exchange of software. Allowing persons to use the message subsystem would only interfere with the primary purpose of the bulletin board. Therefore the SYSOP removes from the menu the functions for leaving and reading messages. To prevent a person from using the functions to leave or read a message (even though they are not displayed), the SYSOP assigns these functions a security level higher than a person who logs on normally would be assigned. Another example of using RBBS-PC's security system would be to set up an agreed upon temporary password such that when a user logs onto the system they can issue the password and get longer than normally allowed. If the time for normal users is 30 minutes, the SYSOP can set up the special password SOFTEXCHANGE, with a maximum time on of 150 minutes instead of the normal 30. By shifting over to this special password after Page 62 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 logging in, members can get extra time if they need it. SOFTWARE SUPPORT -- An author of a freeware program offers RBBS support to all persons who register their copies and send a contribution of, say, $35 per copy. The registered user can get answers for problems and download free updates and sample applications. The author wants anyone to be able to call just to find out about the service. New callers get a security level of 2 automatically assigned to them. This allows them to use only the message subsystem. The file subsystem is assigned a security level of 7. Contributors are added by the SYSOP with a security level of 7 and a pre- assigned password. Except for SYSOP functions, registered users have free reign in the RBBS. CLIENT SUPPORT -- A SYSOP on a public RBBS also works as a management consultant. She has several associates who work with her on projects. She needs to be able to send and receive messages from her associates which the general public should not see. So they agree on a message password NOTPUBLIC. To support her different clients she also needs to leave private files for downloading. To each client she assigns a special downloading password. To restrict downloading to just that client, filenames are put in the file security file with the appropriate password. Only persons with the password can then download them. PRIVILEGED ELECTRONIC MAIL -- A company uses RBBS-PC to help support its regional offices. Only regional vice-presidents should be able to download certain management reports. In file security these reports are assigned a high security level of 9, which only managers get. 12.3 How to Implement the Password File --------------------------------------- Section 7.6.9 describes how the SYSOP can designate the name of the file containing the privileged group passwords to RBBS-PC. Since this file is a normal ASCII file, the SYSOP can use any text editor to create and update the file it. Put the information for each password on a single line and separate the fields with commas. It is important to note that EACH record of both the password or the file security file must contain THREE fields (i.e. two commas). For the password file, the format is: <password>,<security level>,<max time on>. Note: Time is in units of minutes. Two examples are: EXTEND,5,120 ,7,128 If you are using COPY CON to create this file you "MUST" press F6 followed by a Ctrl/Z at the end of the last entry prior to pressing carriage return. A user who issued the password change function and supplied the password EXTEND would have their security level temporarily set to 5 and be granted an elapsed time of 120 minutes for the current session (the user's elasped time per day would still be whatever was set in option 15 of CONFIG). A user who logged on with a security level of 7 would automatically be Page 63 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 granted 128 minutes on the system. 12.4 How to Implement the Security for Download Files ------------------------------------------------------ Section 7.6.4 describes how the SYSOP can designate the name of the file containing the passwords and security levels that can be used to restrict downloads of specific files, volumes, or files names meeting certain "wildcard" criteria. This file contains file names with download restrictions in the format: <filename>, <security level>,<password> Note: Each line is a record and ends with carriage-return line-feed. The only optional field is the password field for a filename. By leaving the password field empty, no password is assigned to a file. The commas between the fields are necessary. YOU MUST HAVE TWO COMMAS ON EACH LINE even if you do not have a password associated with the file. Some examples would be: COMMAND.COM, 10, DOS PAYROLL.DAT, 99, BANKRUPT CALLGIRL.SEX,,ILLEGAL STOCKS,100, The file COMMAND.COM could not be downloaded unless a user had a security level equal to or greater than 10 AND could supply the password "DOS". The file PAYROLL.DAT could not be downloaded unless a user had a security level equal to or greater than 99 AND could supply the password "BANKRUPT". Any user could download the file CALLGIRL.SEX if they could supply the password "ILLEGAL". Any user with a security level of 100 or higher could download the file STOCKS without supplying any password. Additionally "wild-card" characters and drive designators can be used to protect or restrict certain classes of files (by extension, by drive, etc.) from being downloaded. Some examples would be: A:*.*,8, E:*.SEC,2,PW1 A*.M*,0,GX3 XY?X.*,9,3XG All files on drive A would require the users to have a security level of 8 in order for a user to download them. Any user who wanted to download a file whose extension was ".SEC" and was found to be on drive E would have to not only have a security level of at least 2 but to also give the password PW1. The third entry above would require a user who wanted to download any file on any drive with a prefix that began with "A" and an extension that began with "M" to have a security level of at least 0 and to enter the password GX3. Finally, the last entry above would require any user who wanted to download any file on any drive whose four-letter name began with "XY" and whose last letter was "X" with any extension to have a security level of at least 9 and enter the password 3XG. Page 64 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 To get exceptions to the general rule, just put the exceptions first. RBBS-PC's file security search stops with the first applicable entry that it encounters. For example, 1. if you want all files on the B drive to require the user to have a security level of at least 3, 2. except that files on the B drive with the extension ".SEC" would require the user to have a security level of at least 6, and, 3. regardless of the disk drive that they were on, any file beginning with "MES" with an extension of ".SEC" would require the user to have a security level of at least 12 you would enter the following into the file security file MES*.SEC,12, B:*.SEC,6, B:*.*,3 Special Note: RBBS is hard coded so that there are some files that nobody can download -- not even the SYSOP. These are RBBS-PC.DEF, users, messages, callers, group password, comments, the file security, and backup files. Similarly the batch files that control RBBS and let the caller exit to DOS 2 can not be downloaded. The default security file provided with RBBS-PC is empty. 12.5 How to Implement the Security for RBBS-PC Commands -------------------------------------------------------- RBBS-PC allows each command to be assigned it's own security level. A user who wishes to invoke an RBBS-PC command must have at least the same security level as the command. Let's assume that a SYSOP wants to set up the following classes of users: Classification of Users Security Level "Locked Out" Users 0 New Users (first time) 1 Normal Users 2 Users who can "view" a Conference 3 Users who can enter Messages 4 Users who can download files 5 Users who can upload files 6 Users who can Join a Conference 7 Users who can do some SYSOP commands (Jr. SYSOP's) 8 Users who can enter a "door" 9 Users who can enter all SYSOP commands (Co-SYSOP's) 10 Page 65 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 The following table illustrates one method of assigning each RBBS-PC command it's own security level: Subsystem/Command Security Level Assigned to Command Messages Subsystem B>ulletins.......................... 1 C>omments........................... 1 D>oor subsystem..................... 9 E>enter message..................... 4 F>iles system....................... 1 G>oodbye............................ 0 H>elp............................... 1 I>nitial welcome.................... 1 J>oin a conference.................. 7 K>ill messages...................... 4 L>ines per page..................... 1 O>perator page...................... 1 P>ersonal mail...................... 2 Q>uick scan of messages............. 1 R>ead messages...................... 2 S>can messages...................... 1 U>tilities (more)................... 1 V>iew a conference.................. 3 W>ho's on other nodes................3 X>Expert on/off..................... 1 ?>Functions......................... 1 Utilities Subsystem B>aud rate.......................... 1 C>ase change........................ 1 F>ile transfer protocol............. 1 G>raphics........................... 1 H>elp............................... 1 L>ine feeds......................... 1 M>sg Margin......................... 1 N>ulls.............................. 1 P>assword........................... 2 Q>uit to messages subsystem......... 0 R>eview preferences................. 0 S>tatistics......................... 1 T>ime............................... 1 U>serlog............................ 2 X>Expert mode on/off................ 1 !>Prompt Sound...................... 1 Page 66 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 Subsystem/Command Security Level Assigned to Command Files Subsystem D>ownload........................... 5 G>oodbye............................ 0 H>elp............................... 1 L>ist file directories.............. 7 N>ew files.......................... 6 Q>uit to messages subsystem......... 1 S>earch directories for string ..... 1 U>pload a file...................... 6 X>Expert mode on/off................ 1 ?>file transfer information......... 1 SYSOP Subsystem 1>List comments..................... 8 2>List callers log..................10 3>Recover a Message................. 8 4>Erase comments.................... 9 5>USERS maintenance.................10 6>Toggle page bell.................. 8 7>Exit to DOS 2.x or above.......... 9 12.6 Beware of the "Trojan Horse!" ----------------------------------- Despite RBBS-PC's security always remember that you should always assume: "EVERY FILE ON THE PC RUNNING RBBS-PC CAN BE DOWNLOADED, MODIFIED, AND/OR DESTROYED!" RBBS-PC's security system appears to be so fool-proof that some individuals have resorted to uploading programs that appear to do one thing, but actually do something else. These "trojan horse" programs search all the disks that are connected to the PC that the program is running on for such RBBS files as RBBS-PC.DEF or USERS. The program then copies these files to an innocuously named file that can be downloaded later when the person who uploaded it logs onto the system again. Since RBBS-PC.DEF contains the pseudonym that the SYSOP can use to logon on remotely as the SYSOP, once the user downloads a copy of it the user can then log on as the SYSOP and do just about anything including exiting to DOS and formatting all the disks on the system. Similarly, the USERS file contains passwords and the security levels of everyone on your RBBS -- some of whom may have SYSOP privileges. You can protect yourself against anyone logging on as you, the SYSOP, by not allowing anyone to logon as the SYSOP remotely. To do this read section 7.1.1 regarding parameters 3 and 4. You can protect yourself against unauthorized access of the USERS file by simply not allowing any user to have SYSOP privileges. Of course there is the "trojan horse" program that doesn't even bother with the above, but simply destroys all the disk files on all the disks that are connected to the PC that is running the program. Read section 16.0, Uploaded File Tips, regarding how you can protect yourself against such programs. Page 67 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 13.0 SYSOP FUNCTIONS ------------------- The SYSOP functions are not available to the general user, and it should be noted that the SYSOP should not use some of the user functions either because the code will not work correctly if called from the main console, or the function is not for use by the SYSOP. Such functions are the <O>perator, <N>ewbaud, <PW> password, and file upload/download using XMODEM. File download using ASCII can be used to "type" files available for download so they scroll across your screen. To enter the SYSOP mode press the ESC key locally or enter the special 'pass' and 'word' first and last name from a remote terminal. 13.1 SYSOP Commands Within RBBS-PC ---------------------------------- The following operations can then be performed by entering a number only at the command prompt: 1 - Type comments file. The contents of the COMMENTS file is displayed. This file can also be inspected using a TYPE command from DOS. It is a ASCII sequential text file. 2 - Type CALLERS file. A log is maintained of all persons who have called the system. This function will list the file showing the users name and the date and time signed on as well as the names of the files they upload/downloads along with any security violation or errors encountered. This is a random access file of 64-byte records. 3 - Resurrect a message. This function will return a message that has been killed to an active state. If message file has been "packed", the killed messages are no longer recoverable. The function will ask for the message number of the message to be recovered. 4 - Erase the COMMENTS file. This function will erase the comments file by killing the file. Since the file is opened "APPEND," a new comments file will be created the next time a user leaves a comment. 5 - USERS file maintenance. The users file contains entries for each user registered with the system. This function permits the SYSOP to list the file on the display, print the file on the printer (LPT1:) or to perform limited editing of the user file records. In <M>odify mode the following subfunctions are available: A - Add a user to the USERS file. M - Return to the <M>ain menu or function prompt. P - Toggle the printer flag to print entries on the printer. N - New password. Permits the SYSOP to change the password for the user. F - Find User. Permits the SYSOP to locate a user by entering the users name. S - Set the security level of the user. This can be used to lockout or grant special privileges to the user. In <M>odify mode a record will be displayed followed by a subfunction prompt for action. To get to a specific record the record number can be entered at the prompt and if valid that record will be displayed. If the Page 68 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 record number is invalid or an empty c/r is entered then the next record in the file will be displayed. 6 - Toggles the operator page bell on/off and overrides the "office hours" specified in the RBBS-PC.DEF file. 7 - If the SYSOP has logged on remotely and is running RBBS-PC under DOS 2.0 or greater, this function will dynamically setup a batch file to assign the SYSOPS terminal as the main console. It then returns to DOS and if a. RBBS-PC was invoked via a batch file, and if b. that batch file checks for the batch file which RBBS-PC dynamically builds for option 7, and if c. the batch file that invokes RBBS-PC executes the batch file that RBBS-PC dynamically builds for option 7, and if d. the program EXITRBBS.EXE exists on the same drive or in the same DOS sub-directory as RBBS-PC.EXE. The the SYSOP will then see the DOS prompt at the remote terminal and can execute whatever DOS commands or programs the CTTY command support. DOS will look for COMMAND.COM to be present on the disk drive you specified in option 85. Option 7, unlike "doors," loads in a copy of COMMAND.COM to run under the copy that was running RBBS-PC. Also be sure to read section 14 and make sure that you THOROUGHLY understands the limitations that DOS places on you when this option is invoked. Two areas of caution are advised when using option 7 under DOS 2.0 or above. First, each SYSOP should test what can be done remotely. Software that reads and writes directly to the video BIOS and does other things that bypass the standard input and output of DOS simply won't function correctly. Second, you should be aware that you are in DOS and can return to RBBS-PC only by issuing the EXIT command. This will return to the batch file that was built dynamically by RBBS-PC. This file will then continue executing and is designed to reassign the keyboard as the console and then re-invoke RBBS-PC. If you get disconnected while in DOS, your system will be locked up. The console will be assigned to your communication port and your Hayes modem will have dropped the line and will have been set not to auto-answer. The only way to re-boot the system is a manual power off/on sequence. 13.2 SYSOP's Use of Function Keys --------------------------------- The following function keys (ten keys on the left side of a standard IBM keyboard) are designed to give the SYSOP special local controls that can be actuated without entering the SYSOP mode (using the ESC entry key). The current status of the function keys F3, F4, F6 and F7 are displayed on line 25. F1 - Return to DOS. This will terminate a session if a caller is on-line. F2 - SHELL to DOS. RBBS-PC remains resident but suspended in memory, the user (if any) remains on-line and the local SYSOP is in DOS until the EXIT Page 69 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 command is issued (returning to within RBBS-PC just prior to having pressed the F2 key). The users session is not terminated -- only suspended. F3 - Printer toggle on/off. This changes the printer on-line status. When on-line the printer will print each caller's name and the file names uploaded/downloaded. It will also print all error messages except the ERROR 68 used to check that a file exists. This function should match the condition of the printer. If the printer is going to be left off, the PRINTER toggle should be set to off. When the printer toggle is on "LPT," will be displayed in positions 8-11 of line 25. F4 - Operator page toggle. This changes the status of "operator annoy" (i.e. allows the SYSOP to be pageable) and records the change in the "node" record associated with the copy of RBBS-PC associated with function key 4. This is set by the CONFIG program parameter # 7 which establishes the SYSOP's office hours. This can be used to override and extend the "office hours" set up by CONFIG.BAS. When the "operator annoy" toggle is on, "ANY" will be displayed in positions 5-7 of line 25. F5 - Forces RBBS-PC to tell the modem to answer the phone. F6 - SYSOP available. This changes the status of operator available and records the change in the "node" record associated with the copy of RBBS- PC associated with function key 6. This is useful if during your "office hours" you temporarily don't wish to be disturbed. When the sysop available toggle is on, "AVL" will be displayed in positions 1-3 of line 25. F7 - SYSOP gets control of the system after current user logs off. When the "SYSON next" toggle is on, "SYS" will be displayed in positions 13-15 of line 25. F8 - Allows the SYSOP to grant an on-line user temporary SYSOP privileges. This is a toggle on/off switch. Page 70 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 F9 - SNOOP toggle. This changes the SNOOP from the default value the first time it is pressed and toggles it on/off thereafter. "SNOOP off" clears the screen and turns the cursor off. It also keeps the download beeps from sounding. The SNOOP should be left off for normal use to keep the system startup screen from "burning into" the monitor. If the SNOOP is left on, the monitor should be physically turned off except when you are observing the RBBS in action. Leaving the monitor off will not affect performance of the RBBS. F10 - This is the forced chat switch. It announces your forced chat and who you are before turning the keyboard over to you and the caller. The ESC key is used to exit Forced chat mode or to answer an "O>perator page" request. The F10 key will not function until a user logging on has reached the Main Menu. The SYSOP can also enter commands on the command prompt line while a caller is on-line. The command entered will cause the system to respond just as it would if the caller had entered the command. This should be used with caution because it could confuse a new system user -- users are often timid enough without knowing that big brother is actually watching them! Let callers page you and then tell them that you can assist with commands if the get into trouble. Page 71 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 14.0 DOS LIMITATIONS ON RUNNING PROGRAMS REMOTELY ------------------------------------------------- 14.1 How to Get DOS to Monitor Carrier Detect --------------------------------------------- When accessing your PC via a communications port, the carrier detect signal tells the PC that you are on-line. DOS's major limitation is that there is no way to tell DOS to monitor carrier detect automatically when the standard input and output is transferred to a communication port (i.e. via the CTTY command). RBBS-PC makes sure that the carrier is not dropped when a user exits to DOS either via the "DOORS" option or using the remote SYSOP function 8. However, it is the SYSOP's responsibility to insure that whatever programs are invoked after leaving RBBS-PC perform all the necessary functions to maintain the communications session and, when exiting to return to RBBS-PC, that the carrier is "NOT" dropped. Most application programs (i.e. databases, etc.) are not designed to be controlled by users accessing them from a communications port. This problem is solved when a function is invoked that: 1. Checks to see if the standard input and output console have been assigned to an auxiliary console such as a communication port. 2. If condition 1 is true, checks to see if the carrier detect signal is lost by intercepting each interrupt from the communication port the auxiliary console has been assigned to. 3. If BOTH conditions 1 and 2 are true, this function would cause DOS to switch back to the standard screen and keyboard for its operations AND then continue processing whatever batch file that had been executing (if one was). Such a function (or device driver) would provide a "fail safe" feature that would allow users to exit RBBS-PC to use whatever other software the SYSOP chose to make available (i.e. relational databases for complex inquiries -- bibliographic, sports, games, etc.). For those anticipating using RBBS-PC's "doors" or exiting to DOS when you are a remote SYSOP, you are strongly encouraged to consider using the "watchdog" utility program available on many bulletin board systems under such file names as WATCHDOG.COM, WATCHDOG.ASM, WATCHDOG.DOC, WATCHDOG.EXE that monitors the communication port for you and reboots your system if carrier drops. If you don't use a program like WATCHDOG and accidently hang up while in a "door" or in DOS, you system will remain "hung" until you can manually reboot it. If you aren't technically inclined and want to use RBBS-PC "doors", I suggest you consider using MultiLink from The Software Link, Incorporated at (404) 998-0700. While MultiLink costs about $500 and neither RBBS-PC nor CPCUG have any connection with it, it does provide a mechanism for overcoming DOS's inability to have programs invoked from remote users (release 2.0.6 or higher of MultiLink is required). If RBBS detects that MultiLink is present when a user exits to DOS via "doors", RBBS-PC automatically passes control of the communications port that the user is on to MultiLink so that MultiLink can do the carrier monitoring on behalf of the application. Page 72 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 14.2 How to Redirect Graphic Displays to Remote Users ------------------------------------------------------ Programs that utilize the PC's built in video memory (such as the IBM BASIC interpreter or WordStar when it writes to the 25th line) need to have such I/O redirected in a special way to a remote user's terminal. Additionally, if the I/O is redirected to the communications port, the terminal on the other end must have a "cursor" that can be sent the appropriate command sequence to move it around on the remote user's terminal as necessary. Without this capability, programs made available through "doors" must be line-at-a-time programs. This of course excludes programs such as WordStar, Lotus/123 etc. If you aren't technically inclined and want to use RBBS-PC "doors" for applications that write directly to the PC's video hardware, I suggest you consider using MultiLink (see section 14.1). MultiLink provides a mechanism for overcoming DOS's inability to redirect graphics to remote users. If RBBS detects that MultiLink is present when a user exits to DOS via "doors", RBBS-PC automatically passes control of the communications port to MultiLink and notifies MultiLink of the kind of MultiLink-supported terminal to redirect the application's graphics to (presumably one with a controllable cursor). Page 73 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 15.0 CONFERENCING WITH RBBS-PC ------------------------------- RBBS-PC is intended to be an open system. The "conference" concept is one that allows either anyone who can leave messages (i.e. a "public" conference) or a pre-registered set of users (i.e. a "private" conference) to engage in a specialized dialogue. To make a "conference" successful several guidelines should be followed rather rigorously: 1. Establish a "conference chairman" (i.e. a SIGOP) to manage the conference. The SIGOP's job is to add new users, delete old ones, make sure that the subject and/or the agenda of the conference is adhered to by killing messages that are inappropriate. 2. Establish an "agenda" or list of subject areas for the conference. One of these should be about new subject areas. These areas should be VERY narrow in scope. The essence of any good conference is keeping it focused. Everyone has been in at least one meeting/conference that was a waste of time because whoever was running the meeting/conference did not keep the dialogue centered on the subject or agenda. The SYSOP sets up a conference using CONFIG.BAS to pre-format up to two files -- one for the messages to be associated with the conference and one for the users to be associated with a conference (if it is a "private" conference). The file name for a "conference" can be any seven characters that are valid for a file name. The eighth character must be a "M" (for the messages file associated the conference) or a "U" (for the users file associated with the conference). The SYSOP can then enter the conference member's names in the conference USERS file by using the SYSOP function 5. The SYSOP can "join" any conference and need not be in any particular conference's USERS file. To set up a conference chairman, the SYSOP need only 1. "Join" the conference, 2. Use SYSOP function 5 to enter the name of the user who is to be the conference chairperson into the conference's USERS file. 3. Set that user's security level in the conference's USERS file to a security level that can issue the SYSOP function 5. This will allow the conference chairman to add users. Remember that users can join a "private" conference only if already registered in that conference's USERS file. Any registered user can join a "public" conference. When someone issues the J>oin command to join a conference, their standard security level is temporarily superseded by the security level associated with their user name within that conference's USERS file if it is a "private" conference. For example, a normal user might be given the security required to add users to the conference USERS file for a particular conference since they are the conference chairman. When a user joins the conference of which they are chairman, their normal security is bumped up so that they can add users to the USERS file of that particular "private" conference. When the same user exits that conference, their security level is returned to normal. If they should subsequently join another conference in which they are not chairman, they would be unable to add users to that conference's USERS file. Other than a conference chairman, none of the conference Page 74 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 members should be given any higher security than they otherwise enjoy as a regular RBBS-PC users. There are no limits on the number of conferences within RBBS-PC. Here are some examples of some conference names: Conference Name Name of Message File Name of Users File for that for that Conference Conference (if "private") FORSALE FORSALEM.DEF FORSALEU.DEF GAMES GAMESM.DEF GAMESU.DEF FINANCE FINANCEM.DEF FINANCEU.DEF SYSOPS SYSOPSM.DEF SYSOPSU.DEF CLONES CLONESM.DEF CLONESU.DEF RELIGON RELIGONM.DEF RELIGONU.DEF PHILOSP PHILOSPM.DEF PHILOSPU.DEF BBS BBSM.DEF BBSU.DEF If a continuity of dialogue is to be achieved, it is advisable to keep the conference "focused" -- either by keeping the number of conference members limited to thirty persons or less or by keeping the subject matter very narrow (i.e. the IBM PC's 30MB disk size limitation). Another interesting thing about "private" conferences as implemented within RBBS-PC is that they are not "public" and, therefore, are even more protected by the first, fourth, and fifth amendments. Page 75 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 16.0 UPLOADED FILE TIPS ----------------------- If someone uploads a BASIC file to you, and it will not list on your screen using the DOS TYPE command, you should go into BASIC, load the file, list it, then resave it using the same name. If when you try to load the file into the BASIC interpreter you get a `Direct Statement In File' error printed on the screen, the BASIC file has a line without a line number. This will not interfere with the resaving of the file unless the direct statement is at the beginning of the file; if the file lists properly, then the direct statement is at the end of the file. If the file does not list properly, then the direct statement is at the beginning of the file and has to be removed using a text editor (EDLIN) before the program can be loaded and run. Do not attempt to save a BASIC file after getting the `Direct Statement In File' error during loading without listing the program first; you will destroy the file otherwise. If you wish to load an uploaded file (a BASIC program or any other text file) into a text editor to change the content of the file, you will first have tofirst add line feeds to the end of each line (after each carriage return). Finally, every SYSOP should assume that any uploaded file him that can be executed (i.e. .BAS, .COM, .EXE) has the capability of destroying all the files available to the PC it is executed on. This may be because the documentation is in error, the program was executed incorrectly, or the program was designed to be malicious. It behooves every SYSOP to know what every uploaded file does in order to protect not only the RBBS-PC system, but its users. Page 76 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 17.0 DUE WARNING AND SYSOP'S LEGAL LIABILITY -------------------------------------------- While no definitive case-law or legislation exists defining the liabilities of System Operators, every SYSOP should assume that they are as responsible for their own actions when running an electronic bulletin board system as they would be for any other action as a citizen of the United States who chooses to exercise their right to freedom of speech. One of the unique features of RBBS-PC is that users have to OVERTLY register themselves -- even when the RBBS-PC is "open" to the general public. This gives each SYSOP the opportunity to give every user "due notice" and require each user to proactively acknowledge such notice. For some SYSOP's it is simply the rules of their board. For me, the following is what I use as the text in my NEWUSER file: "Welcome to the world of RBBS-PC! Before continuing you should understand your responsibilities as a RBBS-PC user. Specifically they are: 1. Actively encourage and promote the free exchange and discussion of information, ideas and opinions, except when the content would compromise the national security of the United States; violate proprietary rights, personal privacy, or applicable state/federal/local laws and regulations affecting telecommunications; or constitute a crime or libel. 2. Use your real name and fully disclose any personal, financial, or commercial interest when evaluation any specific product or service. 3. Adhere to these rules and notify me immediately when you discover any violations of the rules. FURTHER every user explicitly acknowledges that all information obtained from this RBBS-PC is provided "as is" without warranty of any kind, either expressed or implied, including, but not limited to the implied warranties of merchantability and fitness for a particular purpose and that the entire risk of acting on information obtained from this RBBS-PC, including the entire costs of all necessary remedies, is with those who choose to act on such information and not the operator of this RBBS-PC. Register if you agree." This won't protect you from prosecution if you allow your RBBS-PC to be used for criminal activities. However, it does serve to cause each user to voluntarily and OVERTLY accept my "rules" and allows me to sleep better at night knowing that I have given "due notice." My own personal philosophy is to actively pursue and prosecute ANY user on my board who I find engaging in what appears to be a violation of the above notice. Essentially, if you are going to run an RBBS-PC open to the general publice as I do, your board's reputation and standards must be able to withstand public scrunity. If you don't feel you can maintain such standards, either don't run a RBBS-PC or run a very, very private one (and be sure to put all your assets in the wife's and kid's names). Since I'm not a lawyer, if you want a legal opnion on your liabilities as a SYSOP your only source of legal advice should be an attorney licensed to practice in your state. Just remember it may not be the best advice and that the legal liabilities regarding the operation of bulletin board systems is unclear. Page 77 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 18.0 COMPILING AND LINKING RBBS-PC ---------------------------------- RBBS-PC CPC13-1A's source is distributed along with the executable program RBBS-PC.EXE. It is NOT necessary for anyone running RBBS-PC to recompile or re-link RBBS-PC in order to utilize RBBS-PC. However, some users may wish to modify the source and recompile it. This section is intended for those hardy few who choose to do so. Remember only what is distributed is supported -- anything else is strictly yours to debug! 18.1 Compiling CONFIG.BAS and RBBS-PC.BAS ----------------------------------------- Because of the size of the CONFIG.BAS (version 1.9) the BASIC compiler command should be: BASCOM CONFIG.BAS,, /E/O; The output will be CONFIG.OBJ with a size of about 149,746 bytes. Similarly, because of the size of the RBBS-PC.BAS (version CPC13) the BASIC compiler command should be: BASCOM RBBS-PC.BAS,, /E/C:4096/O; The output will be RBBS-PC.OBJ with a size of about 172,165 bytes. 18.2 LINKing CONFIG ------------------- CONFIG.OBJ can be LINKed to produce CONFIG.EXE with the command LINK CONFIG+xxxCOM,CONFIG.EXE,,C:; assuming that all the required files are on the C drive. The output will be CONFIG.EXE with a size of about 126,306 bytes (or about 124K). NOTE: xxxCOM must be replaced with GWCOM if using the QuickBASIC compiler and IBMCOM if using the IBM Version 2.0 compiler. 18.3 LINKing RBBS-PC -------------------- RBBS-PC.OBJ can be LINKed to produce RBBS-PC.EXE with the LINKer command (all on one line): LINK RBBS-PC+xxxCOM+RBBSMNP+ANSI+XMODEM+RBBSML+BDRIVE2+PC-NET, RBBS-PC.EXE,RBBS-PC.MAP,C:MNP.LIB/MAP/LINE NOTE: xxxCOM must be replaced with GWCOM if using the QuickBASIC compiler and IBMCOM if using the IBM Version 2.0 compiler. The output of the above command will be RBBS-PC.EXE with a size of about 154,986 bytes (or about 152K). MNP file transfer protocol is NOT required to be included in RBBS-PC (see CONFIG's option 31). Therefore, RBBS-PC can be LINKed using the standard LINKer supplied with the Microsoft QuickBASIC compiler and without including either RBBSMNP.OBJ or the MNP library. To do this enter the command: Page 78 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 LINK RBBS-PC+xxxCOM+ANSI+XMODEM+RBBSML+BDRIVE2+PC-NET, RBBS-PC.EXE,RBBS-PC.MAP,/MAP/LINE NOTE: xxxCOM must be replaced with GWCOM if using the QuickBASIC compiler and IBMCOM if using the IBM Version 2.0 compiler. Both of the above LINK commands assume that all the necessary .OBJ files are on the default drive and the necessary .LIB files are on the "C" drive. Microcom's error-free protocol, MNP, is available AS AN OPTION for file transfer beginning with version CPC12-4A of RBBS-PC. The RBBS-PC.EXE file that is distributed includes code from the MNP library. The MNP library file provided with RBBS-PC is done so under the following condition: "The MNP library file provided with RBBS-PC is the exclusive proprietary property of Microcom, Inc. and this copyrighted program material is supplied by Microcom exclusively for use with the RBBS-PC bulletin board system. Inclusion of library code within RBBS-PC does not in any way grant a license to the Microcom Networking Protocol (MNP). The use of the RBBS-PC MNP library code modules or MNP in any product other than the RBBS-PC program is a violation of Microcom's proprietary rights in the MNP technology." Because the Microcom library code was generated by the Lattice C compiler, and because the Lattice C compiler makes assumptions about how data segments are loaded in memory that are incompatible with the way the LINKer supplied with the QuickBASIC compiler, MNP is regretably unavailable with RBBS-PC version CPC13-1A. Hopefully this is only temporary. Page 79 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 19.0 LIMITED LICENSE -------------------- The RBBS-PC software is copyrighted but A LIMITED LICENSE IS GRANTED and each user is free to use and share it under the following conditions: 1. You may NOT distribute RBBS-PC in modified form. 2. You may NOT charge a fee for RBBS-PC itself, and 3. You MUST retain all references to the copyright and authors. Please distribute the original version (or update thereof) of the program. If you have changes please distribute them using the conventions described in section 1.4. This is necessary so that future revisions can be easily added to the system without requiring the entire program. Please do NOT resequence the program. All revisions will be as files that replace the base program or update thereof and the existing line numbers will be referenced whend describing new fixes and enhancements. Page 80 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 20.0 LIMITED WARRANTY --------------------- The RBBS-PC CPC13 program is provided "as is" without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the the quality and performance of the program is with the user, and should the program prove defective, the user and not the authors will assume the entire cost of all necessary remedies. None of the authors warrant that the functions contained in the program will meet any users' requirements or that the operation of the program will be uninterrupted or error-free. In any case, each author's entire liability will be limited to the total amount of money the individual user paid directly and explicitly to each author for the use of RBBS-PC. Page 81 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 21.0 UPGRADING FROM CPC12-5B TO CPC13-1A ---------------------------------------- Before upgrading from CPC13-5B to CPC13-1A, you should follow these five steps: 1. Create backup files of all your current USERS and MESSAGES files. 2. Pack all your current MESSAGES files using CONFIG version 1.8. 3. Rebuild all your current USERS files using CONFIG version 1.8. 4. Re-pack your current your current MESSAGES files using CONFIG version 1.9. 5. Rebuild (again) all your current USERS files using CONFIG version 1.9. PLEASE NOTE!!!!! ---- CPC13-1A has a new CONFIG.BAS (version 1.9 that replaces the older versions of CONFIG.BAS and the .DEF files that they created! Page 82 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 22.0 RBBS-PC FUTURE DIRECTIONS ------------------------------ RBBS-PC can be a lot of fun to operate and can be a useful tool for information exchange. Pass copies of it along to others so that more such will continue to spring up all over the country (and the world)! RBBS-PC seems to be meeting a need within the IBM-compatible PC user community. As you can see from the brief history of RBBS-PC outlined in section 1.3, it has had a rapid evolution in the past two years of it's existence. However, there are some future directions that I see for it and I would like to share them with you. RBBS-PC REDESIGN -- On June 18, 1985 IBM announced a new IBM Personal Computer BASIC Compiler 2.0 and it has been available since the third week in July of 1985 at an unconscionable list price of $495. Microsoft's QuickBasic compiler has been available since August 2, 1985 with a list price of $99. Even with the features of these new compilers, the code segment of RBBS-PC version CPC13-1A is within 155 bytes of the 64K maximum. Fortunately the new compilers allow as many 64K code segments as desired to be linked together into one .EXE file. Obviously, future versions of RBBS- PC will have at least two code segments -- one for the file transfer sub- system and one for the rest of RBBS-PC. In this way, more features can be added to RBBS-PC while still maintaing one .EXE file to be distributed. ADDITIONAL PROTOCOLS -- there is at least one additional protocol that should be added to RBBS-PC. It is one that makes use of CRC16 (cyclic redundancy check) and larger than 128-byte blocks. A "public domain" one exists for the IBM PC and is implemented in Hayes' SMARTCOMII. One SYSOP has already told me he is working on adding that to RBBS-PC. NATIONAL ANNUAL MEETING OF SYSOP'S -- As PC's (IBM's and others) become more common in homes and offices, their use as vehicles for information exchange will grow. Indeed, the growth of RBBS-PC has been astounding! An annual meeting of SYSOP's could foster this growth, the exchange of information, assist in focusing on the issues (regulatory and otherwise) that foster/inhibit this growth, and act as a forum for new ideas. A national meeting, perhaps sponsored by the Capital PC User Group, and initially funded by the major PC manufacturers (Apple, IBM -- are you listening?), valued added network suppliers (MCI, Telenet -- don't miss this untapped market), and the major modem manufacturers (Hayes, Rixon, Racal- Vadic) could be held in Washington in 1986 (at the FCC). The RBBS-PC SYSOPS are not found in the big corporations -- the Fortune 500 have their super mainframes. It is in the millions of small businesses, non-profit associations, educational institutions that the RBBS concept has found a home. As I expect most who would attend would be paying their own way, the first conference would probably consist of that small "band of brothers" who have set up boards out of the intensity of their own commitment. If you are with a manufacturer that might be interested in sponsoring such a meeting in 1985, work with your organization to make it happen! If in the normal course of your business contacts you see a potential sponsor of such a conference, persuade them to look into sponsoring it. My own vision of such a conference is sort of a 1980's electronic "Woodstock" -- if for no other reason because of the very "volks" nature of SYSOPS. It has been a long time since Washington, D.C. has had a conference "of the people, by the people, and for the people." If you are interested, drop me a line here in Great Falls, Va. Page 83 of 108 RBBS-PC CPC13-1A, Copyright 1985 by D. Thomas Mack December 1, 1985 RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD -- The above is not intended to be "all inclusive." My "Userware" concept is founded on the principle stated in section 1.0 -- "software which is shared becomes better than it was." Relying on Federal copyright protection, it is my firm belief that RBBS-PC's source code can be distributed without the risk of "loss of ownership" (i.e. it becoming "public domain"). In fact I think that all software (commercial and non-commercial) should be distributed as both compiled/executable files and with their source code. RBBS-PC's copyrights have never been violated -- this is due more to the fact that RBBS-PC enthusiasts are ever-vigilant of RBBS-PC's copyrights rather than due to any lack of attempts to "sell" RBBS-PC or RBBS-PC look-alikes to the unsuspecting public. Incorporating these new features and ideas into each new release of RBBS- PC, making sure that upward compatability with earlier version of RBBS-PC exists, as well as maintaining RBBS-PC's copyright, are all things that I accept the responsibility for. However, it is RBBS-PC's "support staff" (i.e. all those who enhance RBBS-PC and share such enhancements) that continues to make RBBS-PC a unique experiment in PC software. No one should feel that the above list of "future directions" exhausts all the possibilities for RBBS-PC. In fact, I am absolutely certain that even as this is written innovative enhancements are being created for RBBS-PC that I haven't even mentioned. It is my sincerest hope that if RBBS-PC continues to suceed within the IBM PC industry in becoming the "bulletin- board standard," software vendors will begin examing the reasons for RBBS- PC's success and come to understand that 1. The best form of software support is user support; 2. The best source for software enhancements are from it's users; 3. The best software continually adopts itself to users needs; and 4. The best way to minimize software development is to distribute source code; Each RBBS-PC system operator has the opportunity to affect what RBBS-PC becomes in the future. Many already have. RBBS-PC continues to grow and expand because hundreds (and quite possibly thousands) of SYSOP's spend the time and trouble not only to modify RBBS-PC to meet their needs, but also to share these modifications with others. I do not know of any other software for the IBM PC that has such a vast number of programmers supporting it. In section 1.3, I name almost 50 such individuals and acknowledge that there are a lot more! With the sturctured design of version 13-1A's source code that the new BASIC compilers allowed, even more RBBS-PC system operators are invited to contribute. Take the time! Make the difference! These are only just a few of the ideas that come to mind for RBBS-PC in December of 1985. It will be interesting to see how it evolves. Page 84 of 108